Behold the benefits of code reviewing
Over the past 20 years, I've worked in many different development environments. From IBM mainframes, Digital VAX, and Data General midrange systems to Windows-based PCs, I've reviewed and approved the output of hours of hard work by those around me.
My reviews include code for business systems, clinical information systems, administrative applications, systems services, software and hardware drivers, Web pages, and many other types of programs. The one underlying truth that consistently appears is that all coding efforts run a high risk for defects or standards-compliance violation. These defects could cost billions in reengineering efforts if they make their way into production software. Add to this the liability costs associated with defective software in critical systems such as banking or healthcare applications.
Formalised code reviews can uncover these shortcomings before the code achieves production status. The goals of code reviews are as diverse as the environments in which they're created. However, almost all code reviews have the following objectives in common:
* Quality, defect-free software
* Systems that are appropriate and
complete meeting requirements
* Software that complies with enterprise
coding standards
In addition, many organisations add documentation and supportability to the list. The downside to this list is that it provides no information on how to achieve these goals. For example, quality, defect-free software is a noble objective, but achieving it could take a Herculean effort on the part of the developer and reviewer. Instead, organisations develop coding standards for software development in an effort to pursue these goals. These standards usually address issues of software commonality, performance, supportability, and documentation.
The organisation's development or architecture group usually creates software development standards. The standards should address code at all levels to be successful. This includes presentation, business logic, and data layers. Failure to address software at all layers opens the opportunity for the unreviewed layer to undermine the entire effort.
Standards should also be well documented. This means documentation must be complete, precise, and disseminated to all developers in the enterprise. Successful implementation of standards requires the reviewer to have the authority to reject or disallow proposed software to achieve production status based on the review. This authority should be universal and applied equally in all efforts.
Knowledgeable personnel who are fully versed in the platform technology and organisations standards should perform code reviews. For best results, the review shouldn't be from the same project or development team. In fact, many organisations identify "specialists" that are attached to a separate management structure to conduct the reviews.
The reviewer's job isn't simply to say "yes" or "no" to proposed software. The code reviewer should identify specific lines of code that are noncompliant or in error. Then, formally document this information and return it to the development team submitting the proposed software.
Finally, periodically review the actual coding standards for applicability to the organisation's environment. This is especially important when fundamental changes occur, such as upgrading operating systems or implementing new database solutions.