Goals

Code Reviews have two purposes.

1. To review quality and problem solving approach
2. To make sure that code could be understood by somebody who didn't write it, or wasn't already maintaining it

Why?

Code reviews are an important part of the software development process. Here's why..

Code reviews improve the quality of the code

• The implementer must be able to convey the intent of the code to the reviewer and give an explanation of the implementation.
• The reviewer views the code from a different perspective than the implementer and can spot potential improvements or issues.

Code reviews help with sharing knowledge

• Multiple members of the team end up with a good understanding of the changes
• The implementer has an opportunity to upskill when a reviewer provides suggestions to improve their solution
• Different members of the team are able to review each others code and be exposed to areas of the product they may not have worked on before

How?

Code reviews should be done frequently on small chunks of code

• The smaller the chunk of code the shorter the time of the review
• It's easier for the reviewer to understand small changes as opposed to large complicated changes
• The reviewer is more likely to spot bugs and improvements for small chunks of code
• It's easier to implement improvements suggested by the reviewer as they shouldn't take a lot of effort

Code reviews are done before pushing to the repository

• We only want good quality code in our repository
• Bugs can be dealt with before they get into the product
• It is OK to commit locally before getting a review

The reviewer looks out for the following during a code review

• The code solves the original problem
• Potential issues or improvements to the solution
• The development standards have been followed
• Items on the Definition of Done have been / can be completed
• Could the code be understood by an independent third party?

Code is only pushed when the reviewer is satisfied

• All items brought up in the review should be discussed and fixed where appropriate

See also the Git Workflow page.

Pair Programming

Pair programming is like a code review on steroids! It's essentially an extended code review where both developers get to implement and review the code from start to finish.

Pair programming involves two developers using the same computer to write the code to solve a problem. The two developers should take turns using the keyboard to add code to the solution, with the person at the keyboard acting as the 'driver' and the other acting as the 'navigator'. The driver's job is to implement the solution, and the navigator's job is to review the code as it as typed and provide input to the solution, often thinking about the bigger picture and potential issues that could arise. The two roles should be swapped regularly.

There are a lot of benefits provided by pair programming:

• Pair programming ensures that both developers fully understand the code
• Better solutions are produced as there are two people with different backgrounds and experiences providing input
• Fewer bugs are present in the code as there are two people looking out for them
• Developers are upskilled as they are constantly learning off one another