| Modify or Clone? | KEVIN RESCHENBERG
06-07-2004 |
When customizing functionality in a PeopleSoft system, is it better to
modify an existing object, or "clone" it first to create a new copy?
Last week I discussed the naming of custom objects to
make them easier to identify. But I also suggested that not all custom
objects should be named this way. Some of the PeopleSoft-delivered objects
might be customized but will retain their original names. How can you decide
whether to customize an existing object, or create a new one?
"Cloning" refers to copying an existing object (whether it's delivered or
custom) to create a new object that can then be modified. A cloned object
should be named using your unique identifier.
Note: For SQRs, the procedure is a little different. Today's discussion
is more generally related to record definitions, pages, components,
PeopleCode, and other objects stored in the database. I'll deal with the
differences for SQRs and other file objects next week.
It is easy to see the advantages of cloning. By copying an object before
making modifications, we preserve the original delivered object. The new
object is separate and easily identifiable. This can make upgrades easier.
It also reduces the possibility of unwanted side effects that can occur
when we are changing existing objects. And backing out our changes, if
necessary, is as easy as dropping the new object.
However, cloning also has disadvantages and costs. In some cases it can
lead to more customization than necessary, increase risk, and even
make upgrades more difficult.
For example, suppose that we need
to add a field and make some cosmetic changes to a page. We could clone
the page and make our changes. But then the component(s) that use the
page must be changed (or maybe cloned?). If we create new components,
the menu is affected, security must be changed, and so on. Now instead of
simplifying our next upgrade, we have complicated it.
There is another problem with cloning. Using the same example, suppose that
the next upgrade delivers improvements to the page. We would do our
comparisons and find that the original page had not been modified.
Therefore, we would probably accept the new delivered page and move on.
But what about the cloned version? If we don't know about it or don't make
the connection to the original page, we might forget to apply the new
delivered changes to it. We would have "frozen" the page. It would no longer
match PeopleBooks, it might not work well with other portions of the system—and
the situation would only get worse as future patches are applied.
Let's consider a different situation. We still want to modify the page, but
in this case we need to add new functionality to it. This functionality
should appear only if the page is being run by a new component we are
creating. This could work, but we could end up making the page very complex
and difficult to maintain. Upgrades would be difficult.
In this case, cloning the page would be the best choice.
So how can we decide whether to clone first or simply modify an existing
object? If you intend to create entirely new functionality that has some
similarity to existing functionality, you can often save time by cloning
an object. However, if you want to modify existing functionality, it is
generally better to modify it in place, in the original object. As a very
rough guide, if you intend to change over 50% of the appearance or behavior
of an object, clone it.
(Note that you could clone the object to a backup copy and then modify the
original object. This would allow you to recover the object quickly if
necessary. However, use this technique sparingly or at least develop a
strict naming convention for the backups. Otherwise, these backup copies
will begin to proliferate, and nobody will want to delete them for fear
of breaking the system.)
Let's take another example. Some people would never consider adding a field
to an existing record definition. They would always create a new record
as a "sibling" of the existing record. This can be a good idea. However,
if it is necessary to have a one-to-one correspondence between the two
tables (where a row is always created in the new table for each row in the
original table), then it may be necessary to make page or PeopleCode changes.
If a row is missing from the new table, will this break the system? Will
SQL joins fail? Does creating a new table cause more problems than it solves?
There is nothing wrong with customizing your system, and there is nothing
wrong with customizing existing objects. Cloning objects can be a very
good idea, but contrary to some of the conventional wisdom, it can at times
actually cause more risk and system instability. Before starting your
customization, carefully consider the pros and cons of cloning vs. modifying
objects in place. Don't be pressured into one method or the other by
people who don't understand the implications—explain them clearly.
Choose the best method for the future stability and maintainability of the
system, and everybody will enjoy the benefits.
|
