Code review is easily skipped and yet it is possibly the fastest road to quality, productivity and the assurance that you deliver business value as quickly and cheaply as possible!

What is code review?

Code review is the act of having a programmer check and either reject or sign-off code submitted by another programmer.

If you want a quick rule, every line of code of every software development project should be reviewed by 2 programmers (excluding the person who wrote the code).

Code review is an investment that will deliver higher code quality. But, note, you may not always be targeting a higher level of quality (see Consider your appetite for defects).

In designing your code review practices, be mindful that there are other benefits to code review in addition to quality assurance.

Benefits of code review

Quality assurance

Most obviously, code review allows the reviewers to check for quality. Things the should look for include:

Understandability

Can the code be understood by somebody other than who wrote it? The code should be made of meaningful names and intuitive structure to make it easy to follow. Where this is not enough, the code should be commented with explanations.

Code that is not understandable can significantly affect productivity and maintainability.

Understandability can be supported by comments in the code. There is a general expectation (rule) that at least 10% of the lines in code are actually comments explaining what is going on. Static code analysis can report by module the percentage of lines of code that are comments - highlighting those that fall under the 10% (or other such amount that you prescribe).

Satisfaction of requirements

If the code is understandable, the next thing to confirm is whether the code satisfies the requirements for which it was written. Sounds simple enough, but this requires the reviewers to read the requirements for the piece of code being reviewed and consider whether it is fully and best satisfied.

The toolchain can be used to help direct reviewers to the relevant 'stories' that the code is meant to satisfy.

Knowledge transfer of project

Having only one programmer understand a piece of code is a risk. It can cause lost time and delays whenever the programmer is not available.

In the most serious cases, it is known to be faster to rewrite code than to understand what a particular programmer has done. This can have serious impacts on financial investment and time to market, particularly if you are talking about a whole codebase.

Code review can eliminate this risk. If the code can be understood by one or more reviewers, it is likely than it can be understood by many programmers.

Code review also ensures that there are other programmers who understand the context of the project and can continue developing the code more quickly if any given programmer is not available.

General knowledge transfer between developers

Many different skills can be transferred between programmers as a result of code review. Skills transfer ensures greater consistency and better practices - which in turn improve quality and particularly productivity.

Skills which are inherently transferred include coding practices, logic, use of tools, use of frameworks, etc.

It can also enhance team camaraderie, which also can enhance quality and productivity.

What should code review cover

There are a lot of things that can be considered in code review. To achieve the above outcomes, it is important that reviewers are correctly instructed as to what they are expected to be looking for, ie. the scope of the code review.

• Formatting: Are indentations, space/tabs, bracketing consistent with the style set for the project?
• Style: Are the variables/parameters declared as rules set for the project? Naming conventions: Are field/constant/variable/param/class names meaningful / understandable? Do they conform to the common standards of the project?
• Unit testing: Are unit tests understandable? Is there unit test coverage where you would expect it?
• Architecture: Is the code architecture logical / effective?
• Exception error messages: Is there effective exceptions handling, logging and appropriate / meaningful error messages?
• User-facing messages: Are responses to user appropriate / correct?
• Comments: Are complex sections of code well commented?
• Security and regulatory requirements: Has the code been written with a view to security? Are regulatory requirements satisfied (eg. GDPR)?
• Performance: Is the code efficient?
• External documentation: Are there changes to the codebase that need to be supported by updating external documentation or processes? Some aspects of code review can be automated with static code analysis. But there is nothing like a set of human eyes to ensure that the exercise is complete.

Who and how?

It's common for senior programmers to review the code of junior programmers. But who reviews the code of the most senior programmers? Well, it has to be the junior programmers. This can create some discomfort at first - but it actually makes a lot of sense. Senior programmers have to ensure that their code is understandable by junior programmers and the opportunity for knowledge transfer is just as strong.

Junior programmers need to be encouraged and supported in this role.

Code review can be undertaken as an independent, or asynchronous, code review or as a collaborate activity with the programmer providing a walk through of the code.

Asynchronous code reviews require less coordination. Reviewers use the code review workflow tool to record comments which can be subsequently read by the programmer. The advantage of this approach is that the code needs to speak for itself.

Walkthroughs, on the other hand, provide more personal interaction between programmers, providing a greater opportunity for knowledge transfer, though they do require more coordination and can take longer to execute.

Challenges

There are often pressures to skip or underbake the code review process. These pressures include:

Tight project schedules

Pressure from Project and/or Product Managers can often tempt or even instruct programmers to skip or rush through the review process without achieving the objectives of the code review.

Remember, the reviewers are meant to understand the code, confirm that it satisfies the requirements and that it is well written in all ways. This takes time.

Last minute requirement changes

Late changes, typically the result of a bug or requirement that emerges late, are often committed without sufficient code review.

These late changes are often the result of a Often a bug or requirement that emerges late in release cycle can put time pressure on the team to maintain the release cycle by skipping or rushing through the review process without achieving the objectives of the code review.

Single person projects

When there is only one programmer working on a particular application, it can be more challenging to gain access to programmers who can provide timely review of committed code.

In some ways, code review is even more important on a single person project, as it addresses the risk of only one programmer understanding the code.

Outsourced projects

If some of the software development is outsourced to a 3rd party, what is the best / most appropriate solution for code review? Is it the 3rd party's responsibility or your primary team or both?

Unless it is a pure staff augmentation engagement, it seems irresponsible for the 3rd party to not undertake code review. It also seems irresponsible for your primary team to not review the work of a 3rd party - particularly as your primary team may inherit the maintenance of the code.

So the answer seems to be that both teams have a responsibility to undertake code review, even though this seems to be a duplication of effort. And given that many outsourcing arrangements are prompted to address the need for additional programmers, this can be a significant challenge.

Tools

Reliable code review requires management in a workflow. The workflow allows a programmer to submit a piece of code and alert peers to complete the code review. Reviewers either accept or reject the change. Once the required reviews are positively completed, the submitted code can be merged.

Typical tools used to manage the code review workflow include:

• Gerrit
• Collaborator
• Codebrag
• Codestriker
• Rhodecode
• Phabricator
• Crucible
• Review Assistant
• Review Board