Because code reviews are a great tool to achieve higher quality code in a software development project, we will provide an overview and discuss best practices:
Here at Codacy, code reviews are a crucial step of our development process. We’re currently following a software development methodology where each developer’s work is made in a feature branch, and upon feature completion, a pull request is created for that branch.
To be merged, each pull request requires two approves from other members of that team. We’re using this rule since our team had four developers, and it still works great now, with ten developers.
The pull request is the last control point before code joining the master branch, where production code lives. As a continuous deployment approach, our methodology assumes that once code is merged into the master branch, it’s ready to be deployed. In our case, after a merge the code is built and deployed to a staging environment. The staging environment is periodically or manually promoted to production at any given moment.
Still, code reviews can be a bottleneck in the feature pipeline and delay their deployment. So here are some best practices that worked for us and can help your team to keep a healthy speed.
1 Keep a schedule
Creating a schedule to maintain your team organized is a good way of keeping your team engaged. Reviewing code is often regarded as a “boring” activity by some programmers, so make sure you get everyone involved to minimize the load on each individual developer.
2 Communicate
Before starting to code a new feature, discuss with your colleagues the major design and algorithm choices. This will help you gain a better understanding of the problem and collectively find better solutions. It also makes that reviewers are already familiar with the decisions you made in the code and have an easier time reviewing it.
3 Focus
I do believe in the “Don’t live with broken windows” motto. When you find a piece of code that you feel isn’t as good as it could be, you should always strive to improve it.
However, don’t do it in the middle of a feature. It’ll pollute your branch with unrelated changes, that the reviewer will have a hard time understanding how they relate to the original intent of the pull request.
Instead, you can keep your personal list of things to improve when you’re in between features.
4 Think like you are a code reviewer
Always be your own reviewer! I can’t stress this post enough. Always review your code before handing it over to the reviewers. It’ll help you get a perspective on the changes you made. Use this opportunity to analyze your code with a critical eye and strive for improvements. Think of what a reviewer would ask and clarify the code and/or add comments to explain your intent. This will also help you make sure that your code is definitely ready for review and prevent you from wasting the reviewer’s time.
5 Automate
As a team you should automate the review process as much as you can. Automate builds, tests and static analysis (using Codacy of course 🙂 ). These help to speed reviews immensely. A human reviewer shouldn’t start reviewing if any of those steps fail. (Also, making sure a pull request includes tests for the feature developed is a critical point.)
I hope you and your team find these rules of thumb useful. If you have more tips on how to improve the productivity of code reviews and the happiness of your team, please share them in the comments below.
