What are Code reviews?
Of course, the actual process and implementation of code reviews is a much more complex task! There's an implicit relationship between code quality and code reviews, so it's vital that you understand the best methodology to use, how it fits into the rest of your development process, and which team members take ownership of what.
Code reviews play an important part in the development process, but can often be a source of frustration, so follow these simple rules
Review early. Review often
Many organisations run their code reviews at the end of the development process. This might seem logical, but it's not actually the most efficient approach. Having worked with hundreds of development teams around the world, we've found that the teams that run code reviews before deployment, actually spend the least amount of time fixing bugs and making code changes. That's because, by running code reviews earlier in the process, teams are able to improve productivity by identifying issues before programmers waste time building more code on top of already broken code.
So, by reviewing early, and reviewing often, you can reduce code changes and simplify developer peer reviews.
Setup a process
One of the biggest pitfalls is not establishing a documented code review process. This means that team members don't understand where, when, or why they should review code. Without it, teams can even be mistaken into thinking that the process is actually counter productive, rather than beneficial.
Establish a process that works best for the size of your team, their needs, and level of communication. Establish owners of the code review process, who will conduct the reviews, and who will benefit most from the code reviews.
To help you set-up your own process, try the OWASP Code Review Guide Table.
Use code review checklists
Even the high-level developers on your team can make mistakes when reviewing the code base. The best way to reduce the probability of errors is to use a checklist that takes into consideration the standards and quality that have been established for your product. We've found that teams that have a quality standards checklist actually spend less time fixing bugs and more time building new features.
It is also a great way to keep control of what's been done, and what still needs to be reviewed.
Work with team members
Errors can easily slip through if you work by yourself. By implementing peer code reviews in your development process, you ensure that more than one pair of eyes analyses the code. By doing this, you'll benefit from more effective code reviews, and find new solutions that could have easily been missed if only seen by a single developer.
You might also want to look at letting all of your developers review code from time to time. It brings a sense of ownership and is a great way to spread knowledge across junior team members. On average, developers should spend between 0.5 - 1 day per week reviewing code.
Reporting and fixing bugs
Code reviewing isn't just about the review. The way you report and fix bugs is just as important. That's why you'll need a well structured reporting and fixing process.
For reporting bugs, it's vital to establish what information is important for the programmers. It's also important to define who will be responsible for analysing and prioritising those bugs so you can reduce confusion and wasted effort.
When looking at fixing bugs, you should be clear at what stage of the process the bugs will be addressed and how they might affect pull requests.
Choose the right tools
Even if you had all of your programmers reviewing your source code, mistakes will undoubtedly slip through! Unfortunately, the traditional code review processes can be laborious and time consuming. Some teams might even avoid running code reviews purely because of the perceived time wasted, versus the benefits gained.
Code review tools such as Codacy strive to make the code review process easier through automated analysis, so your team can be more efficient, and improve code quality.
TL;DR (Cheat sheet)
An efficient code review process improves code quality, and creates more productive, and happy engineers. So just remember our simple rules for a good code review practice:
01. Review early. Review often
Run code reviews early and often to identify issues as early as possible.
02. Setup a process.
Have a well-documented code review process and share it with the team so everyone understands its importance.
03.Use code reviews checklists
Establish code quality standards for your product and create a checklist that everyone can refer to.
04. Work with team members
Implement peer reviews, and make sure all your developers get to review code.
05. Reporting and fixing bugs
Document the process for reporting and fixing bugs so that everyone understands how they might impact pull requests.
06. Choose the right tools
Manually reviewing code is time consuming, laborious, and error-prone. Find tools that will drive greater accuracy and efficiency.
The ultimate guide to code reviews - Edition II
Setting up a proper code review workflow might seem like a complex task at first, but by addressing this process early on, you guarantee better results in the long-term. For a more detailed guide, with recommendation drawn from interviews with almost 700 developers, download our ebook.Get this ebook