What do you love about writing code

Why code reviews matter (and actually save time!)

Agile teams organize themselves thanks to cross-team competencies. This is partly achieved through code reviews. With a code review, developers not only get to know the code base, but also learn new technologies and procedures that expand their competencies.

So what exactly is a code review?

When one developer finishes working on a task, another developer looks at the code and asks questions such as:

  • Are there any obvious logic errors in the code?
  • Have all requirement-related cases been implemented?
  • Are the new automated tests sufficient for the new code? Do existing automated tests need to be rewritten to reflect changes in the code?
  • Does the new code comply with existing formatting guidelines?

Code reviews should be integrated into a team's existing process. For example, if a team is using task branching workflows, initiate a code review after all of the code has been written and automated tests have run and passed, but before the code is merged upstream. This ensures that the code reviewer is reviewing the code for problems that machines are missing. It also prevents bad code decisions from affecting main development.

What does this mean for an agile team?

Any team can benefit from code reviews regardless of development methods. Agile teams, however, particularly benefit because the work is decentralized across the entire team. There is never just one only one Person who knows a specific part of the code base. Simply put, code reviews help make knowledge easier to share across the code base and across the team.

Code reviews allow knowledge to be shared

Agile teams are unbeatably flexible: They can take tasks from the backlog and from all Let team members edit. Teams can therefore tackle new tasks together, as nobody is a bottleneck. Full-stack developers can do both front-end and server-side work.

Code reviews for better estimates

Do you remember the section on estimating? Estimating is teamwork and the team can provide more accurate estimates when product knowledge is spread across the team. As new features are added to the existing code, the original developer can provide good feedback and an accurate estimate. In addition, any code reviewer is also faced with the complexities, known issues, and concerns in this area of ​​the code base. The code reviewer is then on the same level of knowledge as the original developer about this part of the code base. This approach allows for multiple knowledgeable inputs that will help make a final estimate more accurate and reliable.

Code reviews allow timeouts

Nobody wants to be the only point of contact for a code area. And nobody wants to have to familiarize themselves with an important area of ​​code that they haven't written - especially not in the event of an emergency in production. Since code reviews distribute knowledge across the team, each team member can take the reins and continue to steer the boat. (Mixed metaphors are very popular with Atlassian!) But the point is, if no developer is a bottleneck, team members can take time out as needed. If you find yourself tied to the version control system desk, a code review is an excellent way to regain your freedom. Be it to take a much-needed vacation or to have time for another area of ​​the product.

Code reviews as a kind of mentor for newer developers

A special aspect of agile methods is that experienced developers act as mentors for new team members. And a code review simplifies conversations about the code base. Often the team's knowledge is hidden in the code and comes to light during a code review. Newer team members can often see significant areas of the code base that have been dragged out over time and require a new perspective. A code review also ensures that new insights are coupled with existing knowledge.

Professional tip:

Make sure that during a code review, not just one experienced team member is reviewing the code of a newer team member. The code review should be done across teams in every direction. Knowledge knows no limits! Of course, a code review can be helpful for newer developers, but it should never be used as a pure mentoring exercise.

But code reviews take time!

Of course they need time. But this time is not wasted - on the contrary.

Here are three ways to tweak this.

At Atlassian, many teams require two reviews of each code before the code is checked into the code base. Sounds like a lot of effort? But it really isn't. An author who chooses a reviewer puts out feelers in all directions. And the input can come from any two developers. This decentralizes the process so that nobody becomes a bottleneck. It also ensures that code reviews are covered across teams.

A code review before upstream merging ensures that no untested code gets into the product. This means that questionable architecture-related decisions at two in the morning and improper use of a factory pattern by the intern will be detected before they can have final (and regrettably) impact on the application.

Use pressure from colleagues for your own benefit

When developers know their code is being reviewed by a teammate, they take extra care to ensure that all tests pass and that the code is designed as well as possible for the review to go smoothly. With this attention, the coding process itself is often smoother and ultimately faster.

If feedback is needed earlier in the development cycle, don't wait for a code review. Early and frequent feedback makes for better code - so don't hesitate to involve others in whatever form. Not only does this improve your work, but it also ensures that your teammates become better code reviewers. And so the positive cycle continues ...!

Agile methods have influenced me both professionally and personally, as I've learned that agility creates the best experiences, both in code and in life in general. My passions are technology, photography and motorcycling - preferably in combination.