Qodana / Static Code Analysis Guide / Code Review for Agile Teams

Code Review for Agile Teams

Code review, the practice of asking other developers to read and provide feedback on your work, plays a key role in Agile software development. Code review as a long, formal process that takes place every month or quarter isn’t compatible with Agile’s short development cycles, but the feedback and collaboration in lightweight code reviews support multiple Agile principles.

Code reviews can improve the quality, architecture, and design of the codebase in several ways:

Quality

A fresh pair of eyes can catch logical flaws and spot subtle edge cases that you may have missed.

It's scientifically proven that we can't always see our own mistakes, which means we rely on our teammates to help us catch them.

Enhancement

Colleagues reviewing your work will bring their own perspective and experience to your code and can challenge assumptions or suggest alternative approaches that you might not have considered.

Surity

The knowledge that at least one other person will be checking your code often acts as a strong motivator to carefully check it yourself and pay attention to details such as choosing descriptive names, including useful comments, and adding good test coverage.

CI/CD Code Analysis

When treated as a team activity, code reviews promote empowered and organized teams by:

Share knowledge within the team

Providing an opportunity to share knowledge within the team, code reviews help new members get up to speed and avoid one person becoming the critical path for a particular area of the software.

Involve all developers

Involving all developers on the team (not just the most senior) in code reviews promotes a culture of shared responsibility, where everyone is invited to contribute to the design and direction of the software.

Create a sense of ownership

Creating a sense of ownership of the codebase empowers Agile development teams to collaborate and identify the best solutions to problems.

Help teams become self-organizing

Helping teams become self-organizing results in more motivated individuals, better results, and a more sustainable way of working than with a top-down approach.

Read related report

Code review in an Agile process

In Agile software development, teams aim to break projects into smaller chunks and deliver them incrementally – this is one of the key Agile code review best practices. Breaking backlog items down so that a new feature is built up in stages allows you to check how your code interacts with the rest of the codebase and get feedback on what you have done so far.

Code reviews form an important part of the feedback loop in this iterative model of software development. By requesting an Agile code review for each incremental piece of work, you create an opportunity to discuss the approach you’ve taken, identify potential flaws or defects, and ensure the code is readable and maintainable for the future.

When working on something new or experimental, it’s common for Agile teams to begin with a spike (timeboxed period of experimentation) to explore the problem and experiment with possible solutions, before deciding how to proceed and write production-level code. In this case, code reviews allow team members to contribute their thoughts on the architecture or technology before significant time has been invested in a particular direction.

It's good practice to treat code review as part of the definition of done for each piece of development work. For teams using Scrum, Kanban, or a variation thereof, developers usually work alone on a ticket or issue and ask for a code review from one or more colleagues once the ticket is complete.

When working on a ticket, ensure that you add new tests and check your changes carefully before requesting a code review. Running automated tests, linters, and static analysis tools (and fixing any issues that you find) before requesting a review ensures the reviewer can focus on checking for things that tools can’t easily catch.

Alternatively, if you have adopted the extreme programming (XP) practice of pair programming, where two developers work together on a single change, you might decide not to have a separate code review stage, as the changes are constantly reviewed by another developer as they are being written.

Often a code review will result in multiple pieces of feedback, such as possible bugs, queries about the chosen design, or suggestions about how the code could be made more robust, secure, maintainable, or performant.

Regardless of whether you’re doing reviews in person or asynchronously over a messaging app or via a code review tool, it’s often beneficial to discuss more complex or contentious points in person – and if you’re using a code review tool, write a summary of the points so you can refer back to the discussion later. The author of the changes is normally responsible for making any necessary changes identified during the review.

Although there are no hard-and-fast rules, many Agile teams choose to make code review a required step before merging changes into the main or another long-lived development branch. In this case, any changes must be resubmitted for review and approved by the reviewer before the work can be considered complete.

Kotlin Case Study

Tools to support Agile Code Reviews

If you’re using a project or workflow management platform to provide a Scrum or Kanban board, consider adding a code review column to the board to remind team members to request a review for each new submission and keep track of how many code reviews are currently pending.

If you’re using a code review tool to record feedback, consider adding a checklist or template to review requests to remind team members of the key things to consider during the review.

Many hosting tools for Git and other version control systems allow you to make code reviews a condition of merging changes into protected branches or trunks. If you have an automated testing and deployment pipeline, you can use the approval to trigger a series of automated builds and tests, as well as deployment to staging or production.

Finally, consider using your code review tool to record metrics relating to code reviews, such as the number of defects discovered, the number of review cycles before approval, the time between reviews being requested and started, and the size or duration of code reviews. You can use the data to demonstrate where reviews add value (for example, if your teammates need convincing or senior management is unsupportive) and to develop guidelines to make your code reviews more effective.

Code Quality in GitHub

Many software development tools designed for Agile teams can be used to support the code review process. If your team is new to code review, these tools can also help embed the practice.

Key takeaways

Building code review into your team’s Agile development process helps improve code quality and share knowledge.

Making code review a team activity, rather than limiting it to one or two senior developers, helps promote shared ownership of the codebase.

Code review – either as a separate activity or as part of pair programming – should form part of the definition of done for each piece of development work.

When using a spike to explore a new problem or experiment with possible architectures, code review helps other team members share ideas before choosing a particular direction.

Agile teams often use peer code review as an approval step before putting code through an automated testing and deployment pipeline.

Source control platforms, project management systems, and code review tools can help embed code reviews as part of the Agile process..

Try Qodana

Code review for Security

Software reviews should span more than simple issues and smells. Keep your codebase secure and compliant with a code review for security.

Python Code Review Checklist

Use our Python code review checklist to help review common mistakes, security flaws, duplications, and more when reviewing code.

What is Technical Debt?

Learn what technical debt is, how it affects software development, and how to manage and reduce it to keep your codebase healthy and maintainable.