I’ve been doing lots of code reviews lately, so, I thought I’d write my thoughts down on this topic …

Objective

So, what’s the objective of a code review? For me, it boils down to asking 2 questions:

• What is being done well?
• What can be done better?

It’s important that the 2nd point is phased like that rather than “What is being done wrong” because that can lead to negative reviews which can be very demotivating.

Benefits

The benefits are:

• Improve team communication and collaboration. If code reviews are part of the development process, the team will naturally start to talk to each other about the code they are writing and work together when solving difficult problems
• Improving the team. Code reviews will surface coding anti-patterns that some members aren’t aware of. They will also surface code good coding patterns that some members aren’t aware of. So, the coding ability of the team improves quicker than it would do without reviews
• Improving the quality and maintainability of the code. If the code doesn’t make sense, it will be surfaced during the review. If the code uses an anti-pattern, it will be surfaced during the review. Silly bugs will also be caught. So, the quality and maintainability is better than it would be without code reviews

Tips for reviewers

• Does the code make sense - can I quickly understand it without asking lots of questions? If not, what can be done to make the code more readable? Point out where you are having trouble making sense of the code and ask the coder to think of a better structure
• Avoid going through how you would have structured the code - just point the coder in the right direction. Telling the coder that they have done it completely wrong and this is the code they should have written is very demotivating
• If knowledge and use of a design pattern would have helped, point the coder at resources to learn the design pattern and suggest adding a task to the backlog to refactor the code using the design pattern
• The code doesn’t need to be improved there and then. The most important thing is that we learn for the next piece of code that is written. Refactoring tasks can generally be put on the backlog
• Avoid getting emotional!
• Look for common problems and focus on those. Avoid spending lots of time on one-off issues
• Look for good things and share these approaches and patterns with the rest of the team
• Only review up to 500 lines of code in a session. Try to review code regularly so that you don’t have to review more, but if you do, split the review up into different sessions