Managing changes that developers make when they are jointly working on some software modules can be very interesting. Without good change- control software—or, more accurately, version-control software—in place, it' s very possible for one developer to make a change to the code and another developer to undo that change at the very next turn.
Two things are required: great documentation of all changes that are implemented, and a place where you can maintain version control of the code. Let' s talk about the change documentation process first.
You probably won ' t want the developers to have to go through a formal change-control process as they' re working on software modules. Major changes to code after it has been finalized, to be sure, must run through your change-control process, but day-to-day coding changes don' t need to be. However, the changes that are made to the code need to be documented in two places: first in a change-control book, intranet site, or other place where coders can keep track of each other' s coding activities; and second in the code itself. Not only should code be liberally commented, but changes that are made to the code should be included in some sort of header that details changes, developer doing the changes, date changes made, etc. You also need some sort of code version software that can act as a repository for the code and as a version-control mechanism. Microsoft has a product that does this called Visual SourceSafe (http: //msdn.microsoft.com/ssafe ); another company that has one is MKS (www.mks .com). There are many others, but these two can serve as examples for you.
Code versioning software allows developers to place their newly created software into a repository. There ' s a check-in/check-out mechanism associated with the archiving of code. New versions of the same piece of code that have been modified are given a new revision number so that a developer uploading the latest and greatest doesn' t overwrite previous versions. This kind of software is a must-have for software development shops; otherwise, the code winds up on developer computers in folders that don't have any common organizational sense.
Was this article helpful?