Code Reviews : Different Types

Automated Reviews

Automate the review where possible. A review conducted by a computer has several benefits:

  • Reduced manual cost of code reviews
  • Fast, consistent, and repeatable
  • Removes emotion from the reviews: pride, ego, and ownership need to be constantly recognized when conducting a review. When offering a critique you should take care to not to step on the author’s feelings. Using an automated process abdicates this responsibility.
  • In some cases you have tools that allow for real-time reviews, such as the Eclipse plug-in CodePro Analytix. These tools perform an examination of the code as it is being written. This is the holy grail of fixing broken windows.

The benefits notwithstanding, it must be acknowledged that the scope of automated reviews is limited to rules and conventions and are hard to extend to study business logic. The latter have to be handled by manual (or peer) examination.

Manual Reviews

From the prior sections you have seen that interactive and build-time tools at your disposal, while a great boon to the review process, cannot substitute for manual review for a certain class of problems. You have to manually review for certain types of improper coding practices. Tools cannot highlight errors of omission as described in the earlier section. Given that, let’s see how a manual review must be conducted.

Participants: The review must focus on different facets of code correctness. Therefore, the participants of a code review must be chosen to satisfy a diverse set of roles.

  • Technical lead: S/he plays the role of the facilitator and moderator
  • The author(s)
  • Quality Assurance: This role focuses on ensuring that the code under examination satisfies the set standards
  • Functional expert: The person who is an expert in the business domain being reviewed

How to conduct: The technical lead will work with the authors to coordinate the review. This process includes:

  • Identifying the participants in the review
  • Determining the amount of preview time
  • Providing the participants the necessary information
    • Requirement/bug fix that was implemented
    • CVS location of the files affected. The lines in the file that were affected by this change.
    • Project reports with coverage and complexity details
    • Review time duration
  • Setting up a meeting to discuss the results of the preview
    • Moderate the meeting – During the actual review the authors will describe the intent of the code and provide an overview of the implementation before the code is examined
    • Capture comments
    • Repeat above steps if necessary

Code Reviews : Purpose

Adherence to coding standards Writing to standards has several benefits, such as a shared vocabulary, which makes the code easier to reuse and maintain. One of the primary focuses of a code review is to ensure abidance with these norms. As you’ll see later, this benefit of a review is best derived in an automated manner. Such an approach has the dual benefit of a machine’s thoroughness while circumventing the cost of a manual review.

Addressing the requirements One of the key goals of a code review is to ensure that the code under scrutiny is feature-complete. Beautiful code that fails to meet user requirements is useless. The review must ensure that the logic does what it is called upon to do.

Code correctness Ensure that the authors are following proper programming techniques as appropriate:

  • Object orientation: Be on the lookout for monolithic, jack-of-all-trades methods.
  • Code reuse: Promote the use of tried and tested (and debugged) APIs and avoid code duplication by recommending the use of available APIs.
  • Adequate and proper documentation: Ensure that the code is amply commented. This is especially important when the logic is complex. Such inline documentation must explain what is being done and not how it is being done.
  • Defensive coding practices: See any number of online resources.
  • Maintainability: The ability to maintain the code is assessed from documentation and code organization.

Errors and omissions A well-written code fragment that abides by all the departmental norms, satisfies requirements, and otherwise “stays within the lines” could still be in error. It is the task of the reviewer to make sure that the code does not make incorrect business/usage assumptions and that all possible usage scenarios are taken into account. A business process expert helping with the review will be quick to spot logic that presupposes the state of the application while the logic is executed. For example, an application that allows guest users cannot be guaranteed to know the current user’s identity.

Test for coverage. Test coverage is a measure of the quality of testing. Tools like Maven and CruiseControl simplify the process of testing and auditing coverage reports. The reviewer must understand the significance of branch and path coverage.

Silo-busting pedagogical aid This tool exposes others in the team to the code. The reviewer gets to read, analyze, and discuss someone else’s work. Such cross-pollination is an excellent way to raise the skill of the entire group. This approach has the added tangential benefit of busting silos of expertise that projects tend to unwittingly foster.

Code Reviews : How To

  1. Ask questions rather than make statements. A statement is accusatory. “You didn’t follow the standard here” is an attack—whether intentional or not. The question, “What was the reasoning behind the approached you used?” is seeking more information. Obviously, that question can’t be said with a sarcastic or condescending tone; but, done correctly, it can often open the developer up to stating their thinking and then asking if there was a better way.
  2. Avoid the “Why” questions. Although extremely difficult at times, avoiding the”Why” questions can substantially improve the mood. Just as a statement is accusatory—so is a why question. Most “Why” questions can be reworded to a question that doesn’t include the word “Why” and the results can be dramatic. For example, “Why didn’t you follow the standards here…” versus “What was the reasoning behind the deviation from the standards here…”
  3. Remember to praise. The purposes of code reviews are not focused at telling developers how they can improve, and not necessarily that they did a good job. Human nature is such that we want and need to be acknowledged for our successes, not just shown our faults. Because development is necessarily a creative work that developers pour their soul into, it often can be close to their hearts. This makes the need for praise even more critical.
  4. Make sure you have good coding standards to reference. Code reviews find their foundation in the coding standards of the organization. Coding standards are supposed to be the shared agreement that the developers have with one another to produce quality, maintainable code. If you’re discussing an item that isn’t in your coding standards, you have some work to do to get the item in the coding standards. You should regularly ask yourself whether the item being discussed is in your coding standards.
  5. Make sure the discussion stays focused on the code and not the coder. Staying focused on the code helps keep the process from becoming personal. You’re not interested in saying the person is a bad person. Instead, you’re looking to generate the best quality code possible.
  6. Remember that there is often more than one way to approach a solution. Although the developer might have coded something differently from how you would have, it isn’t necessarily wrong. The goal is quality, maintainable code. If it meets those goals and follows the coding standards, that’s all you can ask for.