Near Infinity

Code Reviews

By Bryan Weber

Jul 24, 2008

Proposed code review process

  • Identify piece(s) of code to review
  • Notify reviewers
  • Assign grades based on the following criteria
    • Design
    • Cleanliness
    • Test Quality and Coverage
    • Documentation
    • Accuracy Against Estimate
    • Simplicity
    • Meets Requirements
    • Working as Designed
    • Positive User Experience
  • Meet to discuss the grades
  • Take corrective action

Comments

  • The list of criteria is not set in stone or some magical list of categories. These are based on my own personal experiences. You should modify the list as you see fit for your team. For example, if performance or security is critical to your mission, then they should receive special attention!
  • The categories can be weighted to stress certain areas. This can be useful if a team (NOT an individual) needs to stress one area versus other areas. The weights may change over time.
  • Use a grading system that you feel best applies to your software team's practices. This can be a letter grade (A,B,C,D,F), a numerical score (1,2,3,4) or something completely different.
  • The focus should be on the code and not the developer(s). This is not an assessment of team member(s), it is a review of the code after all! Therefore, do not select pieces of code worked on by a developer, rather select code related to your user stories.
  • Use a tool (such as a wiki, issue tracking tool or planning tool) to track your code reviews AND technical debt that is discovered as a result of the code review.
  • DO SOMETHING ABOUT IT. Many organizations conduct code reviews and little corrective action is taken. Be sure to schedule time to address issues uncovered in code reviews!

Looking for feedback!

I'm looking for feedback on this topic. So if you have any comments please either add a comment to this blog post or shoot me an email at bweber at the domain of this website.