On page 28 from “97 Things Every Programmer Should Know” Mattias Karlsson talks about Code Reviews and the benefits of them.
He stated that “Instead of simply correcting mistakes in code, the purpose of code reviews should be to share knowledge and establish common coding guidelines”. I thought “This is very insightful indeed and I must implement it in my team. But with caution”.
The benefits
Let me first enumerate the benefits which I got as a result. Then I will explain how to introduce your team to code reviews.
- Developers started to care a lot more about their code, because it will be read by fellow developers. The readability improved.
- Developers started to produce more tests and code coverage.
- Developers started to be a bit more precise about the cases they are testing.
- Defects were reduced.
- When my fellow junior developers started reviewing my code they have discovered very interesting patterns for testing and their knowledge expanded. My discussion with them was appreciated. Even when I started to explain the code I wrote I started to understand it better.The knowledge in everybody`s heads started to equalize and become more mature.
- We started to get more things done. Trashing time (bug fix time) was reduces.
- Now we, as a team, like to do our code reviews. It helps us become better programmers and team mates.
My concerns
One of my concern was that some of the juniors may look at code reviews as a way to criticize their work and may start acting defensively. Other concern is that the higher level developers may start overlooking it because they do not understand the purpose of it. Third concern – after a while they may forge review bonds – request code review only from your “developer teammate” and evade others because you want your code to pass quickly.
All of the above can hide the goal and the benefits.
My approach
My approach was to take the step and communicate to every one what it is all about and restate it gently – it is not about criticism but about sharing knowledge and understanding. Equalizing the coding knowledge and standards in the team. Then I moved on and gave one of the juniors to review my code and discover a thing or two they did not know about. For example – how to approach unit and integration testing. The conversation was very productive and the dev was happy that now he knows something new. I was happy when I saw the relief in the devs eyes when he realized that code reviews are for the better of the reviews also. And for everybody in the team.
Extinguish all internal fears in the beginning by picking your words carefully. Short after a junior or two examine your code make a discussion. They will appreciate it. After the initial “green light” be very careful not to allow the developers to build request review bonds. Which means one developer to start requesting reviews only from particular developer. They will eventually start overlooking them. Let everybody take his turn.
