Developing software often involves teams of people working together. As the team grows from one, to two, to multiple people, challenges begin to creep in and rob the organization of creative flow. It becomes harder to maintain a continuous culture across different people. Engineering groups are especially prone to these challenges as code is routinely shared between many people throughout the organization. Code reviews help spread knowledge and best practices around code across the team. In this article we’ll take a look at why code reviews are important, and how to optimize the practice.
What is a code review?
Software development is an art that is very much an individual contribution on a collaborative canvas. As individuals, developers need unencumbered blocks of time to become one with the code, and find that zen where code flows through the keyboard. On the team though, collaboration and knowledge transfer are extremely important so that the team can collectively work as one mind. Code reviews are one of the primary practices to engage the whole team.
Code reviews are a key industry practice that helps ensure that the entire team grows along with the code. Some teams work horizontally across database, server, and UI code while others work through different feature areas of the product. Code reviews can help both styles of teams stimulate conversations and learning across the code base.
Why are code reviews valuable?
1. Engineers like (and need) to take vacation – I‘m a firm believer that vacation makes people more productive. If a single engineer owns an area of code, then that responsibility follows them outside of the office. Having a single team member as the critical path makes the team fragile. Code reviews distribute knowledge across the team.
Having a single team member as the critical path makes the team fragile. Code reviews distribute knowledge.
Would you ever build an important server with a single hard drive? RAID systems distribute data across several hard drives in case one drive fails. Shouldn’t you build your team the same way?
2. New employees want to be productive quickly – When bringing someone new into the team, it’s important to do everything possible to help them get up to speed quickly. Code reviews stimulate conversations around code structure, style, and architecture as a natural part of the workday.
New team members can more efficiently and organically merge into the team culture, minimizing the cost of onboarding.
3. Nobody likes bugs – Code reviews are an excellent way for the engineer and the reviewer to discover bugs. Walking through a tricky area of code demands that both parties understand the flow of logic and validate the solution.
4. Team culture evolves – No team stays static. As the team invests more in the product, better engineering paradigms develop. Code reviews help keep everyone engaged and distributes best practices learned across the team. Engineers connect on a more meaningful technical level, and a better product results.
While the best bugs are the ones not coded, code reviews often reveal flaws in logic as a new set of eyes will find things the original engineer didn’t account for. Also, members of the test team are excellent code reviewers as they are experienced in finding issues inside of the code base.
Pro tip: When doing code reviews, keep them focused. An intense review on a sensitive area of code is much better than a bland review across a large code base. In other words,
10 lines of code = 10 issues. 500 lines of code = “looks fine.” Code reviews.
— I Am Devloper (@iamdevloper) November 5, 2013
Aren’t code reviews expensive?
(Eh, not really… keep reading)
I’ve been on a number of teams throughout my career, and inevitably the feedback surfaces that “code reviews inhibit the team.” Yes, code reviews do take time. However, that time is an investment in your team and the code base. The trick is to ensure that code reviews enhance rather than inhibit the team.
1. Structure code reviews asynchronously – Interruptions kill productivity. Every time a developer’s focus is broken, it takes at least 15 minutes to really get back into “the zone.” Using a tool minimizes interruptions. Pull requests in Git allow an engineer to request reviews asynchronously, so when the reviewer is it a natural stopping point, it’s easy for them to provide more effective feedback.
2. Review code in line – While it may seem simple, the best feedback is contextually close to the area of code in question. Using a tool that supports in-line code reviews allows the reviewer to stay focused on the code under review. Additionally, the original developer can see comments exactly at the point in question.
3. Bring all of the resources for an effective code review together – Reviewing code is more than just reviewing code. An effective code reviewer needs access to the original issue, relevant conversations during development, feature branch status, test results, and notes from any prior code review. JIRA’s new development panel aggregates everything code reviewers need to optimize their review.
4. Enable code reviews into the issue workflow – Some teams like to enforce code reviews as a part of the issue workflow. Stash allows repository owners to require at least one approval before merging. JIRA can require code reviews using Crucible inside of the issue workflow. When code has not been reviewed, an engineer cannot transition an issue to done.
5. Makes status visible – One of the other big productivity killers in the team is asking for status. The changes in JIRA’s new workflow designer make it easy to see the flow of work from new to done. New statuses are in blue, In progress statuses are in yellow, and Done statuses are in green.
Reviewing code is a very different task than developing code. If you don’t have a status in JIRA tracking code review, it becomes harder for stakeholders like engineering leads managers to know how close an issue is to completion. Let’s take a look at two agile boards:
We can certainly see all of the work the engineering team is actively working on. Let’s take a look at a second board:
It’s clear now which issues are under active development, and which issues are awaiting review. Project managers and development managers are much more empowered about the state of development on the second board then they are the first. Issues that are under review are significantly less risky to the program than ones underdevelopment as a solution has been proposed.
Still not convinced?
Be agile in your approach. Give it an honest try for a month or two. Using a cumulative flow diagram in JIRA Agile makes it easy to see if code reviews truly are slowing down the team. If so, you’ll see a backup of issues in that status. That being said, it will take the team some time to learn a new process – once the team reaches its stride, then talk about code reviews in your retrospective. If the cost outweighs the value, the learning will still be significant.
Check out more agile tips and tricks from Atlassian.