Code Review

Benefits

• Promotes Openness – Sets the tone for the entire company. Work is scrutinized by other team members

and is welcome.

• Raises Team Standards – Makes sure all engineers share a similarly high level of standards.
• Propels Teamwork – Team members reconcile different viewpoints between reviewer and reviewee. In

these cases, the manager doesn’t have to step in and “be the adult.” It also improves team communication.

• Keeps Security Top of Mind – Team members learn security hands-on and in context of their domain.

Additionally, reviewers and reviewees constantly update their security knowledge.

• Shapes the Culture – People start to think in terms of quality and secure code.

WHAT EXACTLY IS A CODE REVIEW?

A code review is systematic examination (sometimes referred to aspeer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software.

Code review determines what is being done well and what can be done better, it is not a witch hunt, sharing findings makes all developers involved better, and no one size fits all.

This last point is interesting as it implies there are different ways to do code reviews. And, in fact, there are. At a high level there are four primary types of code reviews:

• Formal – A formal code review meeting is held. All participants gather around a conference room table to

go through the code. Reviewers get the code ahead of the meeting and go through, noting things that are good and bad.

• Informal – Rather than a meeting, reviewers are generally emailed the code. They then reply with their

comments.

• Automated – Software analyzes code and flags suspect code that doesn’t follow guidelines or has other

potential issues. Human reviewers then enter additional comments that are sent back to the reviewee.

• Pull Request – Tools like GitHub allow reviewers to look at the Pull Request and comment on it before it’s

merged. However, it can be difficult to see the changed code in context of the entire method or class.

You may find that one of a combination of these types of code reviews work best for your team. When I do my Code Reviews presentation at conferences I am often asked how often should you do a code review. The correct answer is before every merge or check-in. Now let’s turn to the actual practice of a code review.

What are Code Reviews

• A Code review is simply a systematic way of quantifying code quality
• Code reviews are important to continual improvement of your team and code
• By focusing on what is good and what needs improvement in your code, you can be successful
• Code reviews can improve your code if you avoid pitfalls such as politics, blame and 'not built here'

How to Review Code

• Take your experience to bear. You may have more experience than the reviewee. The review can become

mentoring time. The opposite can also be true. If you are less experienced than the reviewee, you can learn some new techniques.

• Find things to laud and things to fix
• No code is perfect. Maintainability is a feature.
• Don’t review too much code at a time.
  • Review 200-400 lines at a time
  • Reviewing the whole code-base is time consuming
• Look for common problems, nor for one-off issues

How Not to Review Code

There are patterns to reviewing code - there are anti patterns too.

• Don't get emotional
• Don't focus on blame
• Don't redesign the code
• Don't judge based on how you would have coded it
• Don't include one-off problems
  • Trying to find patterns to fix, not one-offs