Code Review Tips
Recently we have written a post about the importance of code review. Indeed, we don’t know an IT company that still has not taken advantage of it. But after doing code review for a few years we found a few hacks and techniques that we’d like to share in case if you’re building your own development team or simply looking for a way to make it work a bit more efficiently.
Before we proceed to the tips, note that everything starts with workflow planning. The effective planning should result in short and effective code reviews. If your code review procedures take too much resources or seem to be uncomfortable, then in the long-term perspective it might be better to review the whole team’s workflow instead of someone’s personal productivity.
Code Review is For Everybody
Code review has a lot of advantages: it helps others to get familiar with the code, learn others’ mistakes and simply find out new techniques. Everybody will finds its own pros in the process, and that’s why everybody should perform code review.
Also, if you still prefer having one group writing code and other one reviewing it, such approach may result in the ‘us vs them’ attitude, when code reviewers are apprehended by code writers as know-all critics. And nobody likes such people.
Most developers tell that the code review process is usually effective within an hour. That’s already a big amount of time, since the average attention span of an person is around 20 minutes. If your review is expected to take more time, it’s better to split the process and do breaks. On the other side, as stated before, long code review is not an effective approach in general, so try to decompose your tasks in your workflow into smaller ones and thus write smaller chunks of code.
Here in RubyGarage code review usually takes from 10 to 30 minutes. We assume that if it needs more time, then we didn’t properly build our workflow. For instance, if we need to have a user signing in procedure developed, we’re going to split it into few small tasks: signing via social networks, signing in via email and password, resetting the password, etc.
That’s a tip pretty similar to the previous one: practice shows it gets pretty difficult to review more than 200 lines of code. Some tell reviewing 400 lines of code is a nightmare. So do breaks or even better, build the workflow where developers write small chunks of code to review. If you can’t do that for some reasons, another practice is to make review not after the developer had already written all the code, but, say, everyday. That will allow to follow his progress and help him avoid logical mistakes even prior to making them.
If the time is very limited and you can’t allocate all resources for the complete code review, a popular practice is to check only 20–30% of the code written. In such case all developers will still keep their code in shape in case of review, ensuring its high quality.
Collect ToDo’s and Mistakes
If you are to review some code and want to be sure you will not miss anything, it’s a great idea to write down all the things you must check prior to review. For instance, every time one of us gets to review the code, he pays special attention to its security, business logic implementation and user access rights. You can also have a list of common mistakes developers make in the code that you can go through when reviewing the code.
When we write code here in RubyGarage, we want to make it as readable as possible and thus follow style guides for the languages we use. For instance, here a few useful links:
We also write down some of the most common and expected mistakes in the internal documentation for each project, which is another useful practice for developers.
Make it Painless
If you’re the one who’s going to submit the code for review, be sure your code is crystal-clear and doesn’t require additional explanatory comments. When submitting, provide the necessary context for the reviewer so that he could immediately dive into the code.
We in RubyGarage submit the code for review through the Pull Request feature in GitHub. When using it, you are ought to list the changes made to the code and provided with the ability to discuss the modifications if necessary. That also makes the code review process more effective.
Define Code Readiness
Defining strict requirements for the code that is ready for review should also be a part of wise workflow planning. Here in RubyGarage, prior to each code review every developer should scan the written code for his most common mistakes, then check if enough tests were written for automatic review, and also see if the code was written according to style guide.
Then we have a continuous integration server that checks every new chunk of code after its submission by running a series of previously written automated tests. If the code has passed those tests successfully, GitHub indicates that it’s ready for manual review.
That makes the whole development process much more transparent.
Define Review Goal
The most obvious answer here is that you’re reviewing code for mistakes. However, the review goal should depend on the current project timelines and the team rules. Are you laser-focused on how the code represents the required functionality, or you also want to avoid code smell and lines not following the general style guide? Often you may not have enough time for all of the above-mentioned.
Here in RubyGarage we try to write the best and the most errorless code possible, because practice shows usually you never have time for refactoring or additional code reviews.
Check review effectiveness
Any manager is always interested to make all the processes he manages more effective. How to make the code review effective? The best practice is to set quantifiable goals. For instance, you can check the quality of code by following the number of support tickets over time, or by number of defects injected by development. You might also want to pay attention to terms like defect rate, defect density, inspection rate and tools gathering such metrics.
However, although that’s a great thing to do, not so many teams take advantage of it. Here in RubyGarage developers check review effectiveness manually, by writing down critical defects noticed during review and then discussing them if necessary.
As said above, these are the tips to optimize your code review process, but everything starts with the general workflow in your team. In terms of development process, it defines how you manage code versions, where you upload new chunks of code, how you review them and so on. In RubyGarage we use Git for all of that, and all the rules are defined in something called Git Flow. But we’ll talk about it later…
Originally published at rubygarage.org.