All software companies must take an intentional and structured approach to code reviews. Still, there is no “one-size-fits-all” approach for code reviews; it varies depending on the codebase, the company’s size, and the team’s preferences.
When a company is starting out, code reviews should look different than during rapid growth, or product maturity.
Here’s a quick guide to figuring it out for your team and development stage:
- If a product is just starting to be built, at the earliest stages, such as during a hackathon or simplest minimum viable product, then code reviews are not necessary. At this stage, they only get in the way. The team should just figure out what functionality should be created and do their best.
- After that stage, code reviews ramp up in importance. Early-stage companies might want to pick one person on the team to do all of the code reviews. This has the benefit of simplicity and speed but comes at the expense of a shared and varied learning experience.
- As a company grows, more people should be performing code reviews. As a rule of thumb, all senior engineers should do code reviews when a company is in the rapid growth phase. In this phase, we are assuming that speed is still essential.
- As the company matures, and as there is more capacity, code reviews should be carried out by seniors and mid-level engineers.
- Finally, as the codebase becomes mature, and the team has more capacity, all engineers including junior engineers should participate in the code review process. Note that the juniors will not only need training, but their reviews will also likely need a second evaluation by someone more experienced. Here, a major goal of code reviews is as a teaching tool for junior engineers.
Clear coding standards, readily available
Next, if your organization has documentation about coding guidelines or content specific to your code, make sure it is readily available and accessible to the code reviewers so that they don’t have to search everywhere for what to include. See a discussion of linters, below.
Give code reviews gravity
Make sure that code review work is as valued as coding — both activities should have equal weightage and visibility.
There are many ways to do this: from celebrating engineers who have done a lot of code reviews, to discussing code reviews at informal check-ins, to including contributions to code reviews as part of the annual performance process.
If code reviews are not important based on recognition, rewards, and other consequences, it doesn’t matter what is said on paper.
Do you have a “great developer” who refuses to do code reviews or refuses to act on feedback from others? What happens to them? That’s one of the clearest signals to the rest of the organization about how much code reviews actually matter.
Originally published at https://www.semasoftware.com.
