English | EN 
A lot of companies struggle with code reviews. They are finding that developers are complaining they take too much time. IT managers are disappointed that coding errors are not being caught. All this leaves many IT teams questioning if peer code reviews are worth all the effort.
The fact is, study after study shows that people are more accountable when they know someone is watching them. Just like dieters are more likely to rethink what they put in their mouth if they know someone is watching, developers are more likely to write better code if they know it will be reviewed.
So why not just rely on testers to find issues? While critically important, testing alone is not enough.
First off, it is much cheaper to fix bugs before they get to testing. When developers find code errors during peer code review they can be fixed immediately saving valuable overall development time. Testers are also do not end up retesting the same story twice.
Secondly, testing will only identify current issues and do not reveal the potential for future issues that code reviewers could find. Obviously, code reviewers will make sure the code meets the user requirements but Ideally code reviewers should dig deeper and should ensure the code fits in the overall architecture and should look for potential security risks and maintainability of the code.
And lastly, peer code reviews result in knowledge sharing which can result in consistent coding and more maintainable code. Code will be far more maintainable when code reviews ensure sufficient annotation and appropriate naming conventions and styles are used. Plus the very act of having a second developer analyze another piece of code automatically makes them experts on the code.
With such obvious benefits why then are companies not seeing meaningful results from peer code reviews? In many instances, this is because the developers that are asked to do code reviews are not given clear instructions and do not see the value in it. At best, they might give it a cursory glance leading to mediocre results.
To truly get your developers to embrace code review you will have to make it part of your team norms. The best teams use a checklist of coding standards with specific items to look for such as style and naming guidelines, security risks, inefficient code, reusable code, test coverage, annotations, and readability. They also make it part of a developers job by allowing time each sprint for reviews. Equally important they include peer code review tasks in the developer’s job descriptions and performance reviews.
As you can see with a little effort in coaching your developers on how to perform code reviews and by creating a checklist on what to look for you can get big returns with more maintainable and error-free code.
