Make Code Review a Regular Part of Your Development Process
By Steven Feuerstein, Quest Software

Software is written to be executed by a machine. These machines are very, very fast, but they are not 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 are not going to be able to tell us if we missed the mark ("garbage in, garbage out" or, unfortunately, "garbage in, gospel out"). The usual way we validate our 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 are not enough.

It is certainly possible that our tests are not 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. The code might work "by accident" (two errors cancel themselves out), for instance.

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 a 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 the 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 the deadline crunch. Further, a new PL/SQL project might not have the language expertise available on the team to do complete, meaningful walkthroughs.

About the Author

Steven Feuerstein, senior technology advisor with Quest Software, is considered one of the world's leading experts on the Oracle PL/SQL language. He is the author or coauthor of seven books, all published by O'Reilly & Associates. His eighth book, "Oracle PL/SQL Best Practices" is due in bookstores April 15, 2001. Steven has been developing software since 1980, and worked for Oracle from 1987 - 1992. Steven hosts the PL/SQL Pipeline, an online community for PL/SQL developers (http://www.revealnet.com/Pipelines/PLSQL/index.htm) and contributes to RevealNet's knowledge Base for Active PL/SQL Development. Finally, Steven is President of the board of directors of the Crossroads Fund, which makes grants to Chicago-area organizations working for social, racial and economic justice. You can reach Steven at steven.feuerstein@quest.com