Section 7.6. Be Careful with Existing Projects


7.6. Be Careful with Existing Projects

An overeager project manager can easily sour a programming team on these tools, if the team doesn't see the benefits. While it's easy for a team to migrate an existing project to a new version control system, it is much harder to begin to build unit tests for an existing codebase. (It's also much more risky, since the old repository can be kept around so that the code can be moved right back if the new version control system does not work out.)

Migrating from files stored in a folder to Subversion is trivialjust build the repository, import the files, and rename the old folder. Migrating from an antiquated source control system to Subversion is a little more involved, but it's still relatively straightforward. The simplest way to do it is to import a copy of the latest revision. This will not make previous changes available in Subversion; however, an Internet search will usually turn up scripts that will automatically import repositories from the most popular version systems into Subversion. Either way, as long as the old repository is kept around in case of disaster, migrating to Subversion can be done at any time, and it can bring immediate benefits to both new and legacy projects.

Refactoring can also bring immediate benefits, but programmers should be careful about how it is applied. It is generally safest to introduce refactoring in code reviews and bug fixes. This will ensure that the benefits of refactoring are applied to where they will do the most good: complex, difficult-to-maintain, or bug-ridden code. Refactoring can also be implemented in new development tasks without much difficulty, as long as the programmers doing the refactoring feel comfortable with the task. However, it is usually a mistake to just pick a block of code at random and try to refactor it. While the refactoring will probably work just fine, the benefits will not be noticed by the programming team, and they will start to question its usefulness.

Many people are uncomfortable introducing refactoring unless there are already unit tests in place. Unit tests are often considered a necessary prerequisite for refactoring, because they ensure that the refactoring does not change the behavior of the code. However, while having unit tests in place is the ideal situation, it is still possible to gain many of the benefits of refactoring without unit tests, as long as the refactored code is thoroughly reviewed in order to find any defects that may have been introduced. This is another reason code reviews and refactoring should be combined.

Unit testing should probably be avoided on large legacy code, and kept to new development. While it is possible to develop unit tests for older code, and those tests will probably catch defects, the process of building them will be very time consuming. This is because it's necessary to fully understand the behavior of a block of code before writing its unit tests, and regaining that understanding usually requires a large ramp-up period for the programmer to familiarize herself with code that has not been touched recently. This ramp-up will probably require a lot of reverse engineering, and may require the programmer to dig around to recover requirements that are unclear from the code and were never written down. Most programmers forced to go through this exercise will be turned off to unit testing entirely. When unit testing is being introduced to an organization, it should generally be confined to new code until the programmers are comfortable using test-driven development in their daily tasks.



Applied Software Project Management
Applied Software Project Management
ISBN: 0596009488
EAN: 2147483647
Year: 2003
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net