Here’s a mind map of what I take into consideration when doing a code review. Some of these things only apply to team reviews.
Click image to expand
Before running a code review, you need to be aware of the negatives and positives.
On the negative side, you need to make sure the developer whose code is being reviewed does not feel like they’re being “beat up” by the rest of the team. You also need to stay focused on the important issues – and not argue about the placement of curly-braces.
When you control the negatives, team code reviews have huge positive impacts.
Besides being the most effective way of finding potential problems, code reviews help your team members become familiar with parts of the code they normally don’t work on – making it easier for them to fill in for the other programmers. It’s also a great way to train your junior developers. They see better ways to write their code, based on what the senior developers know works.
And the most important thing – after the code review, ensure the changes are made to the code. Code reviews aren’t a way for the developers to spend time chatting with each other. They are ways to improve your code. So, make sure the fixes and improvements are actually applied to the program.
I haven’t found any good books on code reviews yet.
However, these books discuss some of the code qualities issues you might find during a code review, and how to improve your existing source code.