Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

December 10, 2003

Of Code Reviews And Donuts

Development reviews are an important tool for encouraging high quality, maintainable software. Here are some tips on how to optimize code reviews.

by Robert Northrop

Continued from Page 1

It's About Responsibility

A common development review shortcoming is the absence of reviewer accountability. The industry's current practices are the equivalent of placing a ticket inside the jeans that says nothing more than "inspected." Well-defined roles are critical to ensuring that a process works; I suggest filling the following roles on an application-by-application basis:

Lead reviewer. This person, a peer developer, should have a significant stake in maintaining the application after production. The lead reviewer is primarily responsible for the application's quality. This person runs the review meetings and delegates tasks among secondary reviewers as necessary. The lead reviewer retains this role throughout the application's life cycle.
Secondary reviewers. These developers also have future responsibility to maintain the application. They primarily focus on reviewing specific aspects of large applications.
Supervisory reviewer. This role is usually filled by an architect-level resource. The supervisory reviewer's focus is primarily governance, consistency, and education of less experienced developers. This role is responsible for identifying ways to improve the reviews themselves.
Recorder. The recorder's responsibility is to track and archive the feedback from the review sessions. This role should be served by someone with technical knowledge, such as a junior developer.
Developer(s). The developers who wrote the artifacts should attend the review to receive feedback on their work.

It's About Preparation

Regardless of established processes or roles and responsibilities, development artifact review sessions with poor preparation have little value. Effective guidelines for preparation include:

Don't review until the deliverable is in a stable state. Although reviewing development artifacts early is important, reviewing too early can be a waste of time.
Limit the scope of the review. One of the reviewer's key responsibilities is selecting the appropriate amount of content to review. If generating the hard copy review artifacts puts you on the EPA's watch list, you should focus on reviewing selections from the artifacts that are most critical.
Use tools to limit the amount that humans need to review. Coding tools such as standards compliance checkers and dependency analyzers will be much more thorough than humans and should be run before submitting work for review. In addition to providing tactical effectiveness, these tools should force the human reviewers to find issues more critical than standards violations.
Resolve or address issues introduced in previous reviews before reviewing again. Discussing an existing but unaddressed issue may prevent the reviewers from finding new ones.

It's About Investment

Effective reviews don't just improve the actual artifacts but the entire development process. Every review should be seen as an investment in improving a future software development endeavor. Organizations that are serious about doing reviews effectively should collect and maintain a set of review guidelines. These guidelines help keep reviews objective. They should include checklists, recommended patterns, and antipatterns or bug patterns to avoid. As new best practices are discovered both within an organization and within an industry, the guidelines should be updated accordingly.

Rate This Article

Comments:

Optional e-mail address:

For my development teams, I currently rely on a listing of more than 100 guidelines that cover requirements, design, test case, and code reviews. With proper process, responsibility, preparation, and investment, you can optimize your code reviews to provide real value to the enterprise by getting more right the first time, and requiring less time to fix mistakes found later.

Robert Northrop [robert.northrop@tallan.com] is a director of design and development with Tallan, a professional services company specializing in developing custom technology solutions for its clients.

RESOURCES

JUnit - Bug Patterns: www.junit.org/news/article/bug_patterns/index.htm