Name
DEV-03: Walk through each other’s code.
Synopsis
Software is written to be executed by a machine. These machines are very, very fast, but they aren’t terribly smart. They simply do what they are told, following the instructions of the software we write, as well as the many other layers of software that control the CPU, storage, memory, etc.
It is extremely important, therefore, that we make sure the code we write does the right thing. Our computers can’t tell us if we missed the mark (“garbage in, garbage out” or, unfortunately, “garbage in, gospel out”). The usual way we validate code is by running that code and checking the outcomes (well, actually, in most cases we have our users run the code and let us know about failures). Such tests are, of course, crucial and must be made. But they aren’t enough.
It is certainly possible that our tests aren’t comprehensive and leave errors undetected. It is also conceivable that the way in which our code was written produces the correct results in very undesirable ways. For instance, the code might work “by accident” (two errors cancel themselves out).
A crucial complement to formal testing of code is a formalized process of code review or walk-through. Code review involves having other developers actually read and review your source code. This review process can take many different forms, including:
The buddy system: Each programmer is assigned another programmer to be ready at any time to look at his buddy’s code and to offer feedback.
Formal code walkthroughs : On a regular basis (and certainly as a “gate” before any program moves to production status), a developer presents or “walks through” her code before a group of programmers.
Pair programming : No one codes alone! Whenever you write software, you do it in pairs, where one person handles the tactical work (thinks about the specific code to be written and does the typing), while the second person takes the strategic role (keeps an eye on the overall architecture, looks out for possible bugs, and generally critiques—always constructively). Pair programming is an integral part of Extreme Programming.
Benefits
Overall quality of code increases dramatically. The architecture of the application tends to be sounder, and the number of bugs in production code goes way down. A further advantage is that of staff education—not just awareness of the project, but also an increase in technological proficiency due to the synergistic effect of working together.
Challenges
The development manager or team leader must take the initiative to set up the code review process and must give developers the time (and training) to do it right. Also, code review seems to be the first casualty of deadline crunch. Further, a new PL/SQL project might not have the language expertise available on the team to do complete, meaningful walkthroughs.
Resources
Handbook of Walkthroughs, Inspections, and Technical Reviews, by Daniel Freedman and Gerald M. Weinberg (Dorset House). Now in its third edition, this book uses a question-and-answer format to show you exactly how to implement reviews for all sorts of product and software development.
Extreme Programming Explained, by Kent Beck (Addison Wesley). The first book on Extreme Programming offers many insights into pair programming.
Extreme Programming Installed, by Ron Jeffries, Ann Anderson, and Chet Hendrickson (Addison Wesley). Focuses on how to implement Extreme Programming in your environment.