Developer's code reviews and varsion control

Question

Hi,
Suppose I am planning to hire 10 apex developers to work on some internet project.
How can I organize the code review process?
How can I see what code a developer has changed and what exactly he's changed in the code?
How can I see the code before it has been changed?
How to see the properties of any object is changed and by whom?
Is it possible to use any control version system with apex development process?
Thanks.

Answer 1

Joel_C wrote:
I agree with your approach - delegating to packages is definitely a sensible method. However, I'm interested to know the degree to which you delegate.It depends... !
For example, do you explicitly reference page items in your packages (perhaps via the 'V' function and APEX_UTIL.SET_SESSION_STATE calls), or do you tend to pass them via parameterized procedure calls? In which case, how do you deal with multiple page items (by which I mean, more than 3 or 4).If there is just a parameter or two being passed from the page, I tend to pass them as parameters from the page process. Very often, all you need to pass is the primary key (ID) of the entity you are working on. So I would write code like this in a page process:
begin
  foo_pkg.delete_foo (:p10_foo_id);
end;Other times, you may need to get the values of several (or all) items on a page. This would typically be when you want to write your own update logic instead of relying on the built-in Automatic Row Processing. Of course this is more work, but you typically only do this for the important entities/pages anyway, so it's worth it for the extra control.
The question then is, should I write something like this:
begin
  foo_pkg.update_foo (:p10_foo_id, :p10_foo_name, :p10_foo_description, :p10_foo_date, :p10_foo_remarks, :p10_foo_link);
end;or just do
begin
  foo_pkg.update_foo;
end;and use V('P10_FOO_ID') or apex_util.get_session_state ('P10_FOO_ID') inside my packaged PL/SQL code to retrieve the item values?
I've used both approaches, but I prefer to use the second option if I know (or suspect) that there is going to be additional logic (ie, "if X then get value of item Y, otherwise get value of item Z"). Having this kind of stuff in a package means that it can be changed easily, without having to redeploy the Apex application.
Said another way, I don't want any "IF" statements in Page Process code.
I'm interested in this, relating to my previous posting about testing - it's kind of difficult to unit test Apex application elements unless you fully modularize your code but there has to be a balance between modular, reusable code and page-specific, item-level code.My approach is two use two layers of packages. Let's say we are building a system that handles invoices. I would create a package called INVOICE_PKG that contains functions such as new_invoice and get_invoice, and procedures such as delete_invoice and set_invoice. This is your "core API" for working with invoices. This package is never called by the client (the Apex application, or a Java program, or whatever) directly.
I then create another package, INVOICE_WEB_PKG, which exposes the functions and procedures that the client needs to call. This package just calls INVOICE_PKG to do the actual work. In this outer package, I can decide whether I want to use input parameters or just get the values from Apex session state.
So a page process on a page with lots of page items could look like this:
begin
  invoice_web_pkg.set_invoice;
end;And the code inside INVOICE_WEB_PKG could look like this:
procedure set_invoice
as
  l_invoice invoice%rowtype;
begin
  l_invoice.invoice_id := apex_util.get_session_state ('P10_INVOICE_ID');
  l_invoice.invoice_date := apex_util.get_session_state ('P10_INVOICE_DATE');
  -- and so on for many more items
  invoice_pkg.set_invoice (l_invoice);
end;BTW, if you download my Alexandria Library for PL/SQL (http://code.google.com/p/plsql-utils/), you will find an APEX_UTIL_PKG that has a couple of wrapper functions to get and set page items (strings, numbers, dates).
By having two layers of packages, you can write unit tests (and other non-GUI code) against the inner package, and leave all the GUI/Apex-specific stuff in the outer package. For example, any code that formats content with HTML or prints anything to the browser (using HTP.P) should go in the outer package.
- Morten
http://ora-00001.blogspot.com