Best practices for effective & efficient agile code reviews

Code review is the process of letting a person other than the original code developer (known as a reviewer) inspect or review code. Some developers do review their own code before checking their new changes.

In Steve McConnell's book Code Complete, code reviewing is explained as one of the cheapest and most effective ways to find bugs and improve code quality. For a summary of McConnell’s most effective methods, we’d highly recommend Kevin Burk’s blog post.

Code reviews can be done both formally and informally. You can do them in different steps of the software production life cycle. And they can be done by either developers (a senior developer with a QA manager role, some senior developers arbitrarily, or developers in general) or by members of a QA or QC test team.

In companies with more resources, large and disciplined teams try to practice formal code reviewing. Formal code reviewing was broadly introduced by IBM’s Michael Fagan in 1986 and has 7 different steps practiced by 3 or 4 people.

As an alternative, there is lightweight code review. It is more popular in agile teams because it is less expensive (both in time and other resources) and is still an effective method to minimize bugs and improve source code quality.

Lightweight code review is usually done by one or several of the following methods:

• Practicing pair programming
• Having over-the-shoulder review sessions for discussion and inspection
• Sending code via e-mail and asking for reviews
• Using third-party tools to let developers share and give feedback

Performing peer code reviews in an ad-hoc, informal way is also effective because it lets developers adopt the best method for themselves and their teams based on their culture and resources.

A team can start by setting this rule:

Don’t deploy unreviewed code into production (as you never deploy code without testing it)

And the code review methods should develop organically from there.

Queue-it’s product, an online queuing system, is composed of different parts. The queue engine module is a critical piece of software that runs 24/7 and handles massive numbers of end-user requests per minute (10,000 requests per minute) in a distributed environment. It has the responsibility to queue requests coming to different resources (i.e. a web page) and de-queue requests at the right time and serve them (redirect them to their target URLs).

For Queue-it developers, it is important to have as few bugs and errors as possible that might disturb this process (queue service should have a 99.9% working time as a cloud service). In our software development process, besides having different test types (Unit, UI and integration testing), we have a strict but informal procedure for reviewing codes: code changes should never go to production before they are reviewed (even for small bug fixes).

For us, it is important that code reviews are not just a senior team member reviewing a junior team member’s code. Code reviews should happen across the team, in every direction.

As an agile software company, Queue-it practices and achieves positive results from our informal code reviewing, which is incorporated into our lean/agile software development process as one step.

1. When a developer finishes a small task and its unit tests, he or she submits it into code our repository.
2. The original developer will send a message containing the task and its change-set ID (to be used to by reviewer for retrieving new changes from the repository).
3. Then another developer reviews the code. The reviewer does a code inspection to see if the code has bugs, if it follows coding conventions and software best practices, etc.
4. A functional test is then performed (doing integration or system testing).
5. If the code has a bug or if the reviewer has comments (which commonly happens), the user story will be placed back at the previous step in our Kanban board (under development), and this process is repeated until the code is perfected.

This process is informal and can be done by messaging, e-mailing, Skype calling, or sitting together at one computer and discussing.

With bigger tasks, developers shelve their code (that is usually not completed or fully unit tested) and ask for reviews. Shelving is a Microsoft TFS practice where you save changes into the code repository server without checking the new code in. This lets codes be shared and accessed between developers. Therefore, architectural/design code reviews can be made by other developers without breaking the build and before actually committing the new code.

After the primary review (once, in our case) is done and when the code is completed, the same workflow as what was described in our small task process occurs.

Queue-it code review best practices include defining short user stories, generating short code review tasks (in terms of time), combining code review with functional testing, and performing non-blocking code reviews.

1. The secret behind our painless code reviews is to break them into short users stories and tasks. This means only a few lines of code changes for each story, which results in a short review time (usually between 15 minutes to 1 hour for normal tasks, and up to 3 hours for bigger tasks).
2. We consolidate functional testing with review tasks in our short stories. This means the reviewer both does a code inspection and makes sure that the functional requirement of the user story is satisfied. Combining these saves resources, as the reviewer spends time with the user story and understands its requirements. Therefore he or she can perform an insightful functional test as well as a code review.
3. Our review tasks usually are non-blocking, so developers are free to commit their changes (we do post-commit reviews for small stories) and then ask another developer to review their codes while they continue with their other user stories. Generally, we do not get many tasks waiting for reviews because reviewing does not take a long amount of time. This means small code review tasks happen in one day and the owner of the story can continue with code review results in the next day.

Related: Code Review Check-ins: Smaller Steps to Efficiency

Generally, there are different factors to consider when performing code inspections, including coding style, comments, and finding defects. Error-prone parts of code is, therefore, a good place to start, including control structures and logically rich pieces of code.

We also look for how the code handles multithreading and performance. The other factor is code quality: Does it follow coding best practices and patterns (like SOLID etc.) and our internal coding standards (is it consistent with our code base)? Have code changes been unit tested, had exception handling and logging (if any), etc.?

We would also recommend reading the many useful review guidelines and review checklist articles out there to give you inspiration.

Related: 3 Simple Ways to Make Your Code Human-Centric

Of the many agile code review benefits, these are the situations where we find it especially efficient and effective:

Code reviewing easily and effectively helps us in finding functional defects, especially in areas where unit testing is harder, such as in JavaScript codes, cases where doing a unit test is incorrect (either a mistake or due to a vague requirement), or cases where unit tests don’t cover the error situation.

Code reviewing easily and effectively helps us discover functional defects, especially in areas where unit testing is harder, such as in JavaScript codes, cases where doing a unit test is incorrect (either a mistake or due to a vague requirement), or cases where unit tests don’t cover the error situation.

Yes, names and comments are important (even for an agile team). We want to share readable code that we can eventually share, so our reviewers focus on how precise and understandable our code is.

Code reviews provide non-stop learning and training, no matter your coding level. And it lets developers share new features (of the language, framework, or tools, etc.) or technical tricks that you may have not seen or used before. You can improve your skills and repertoire by code reviewing with your peers.

We share knowledge about our individual tasks with our teammates so that everyone distributes responsibility and specialties equally, which means we can always cover other tasks in case someone is on holiday.

We have used code reviewing to make new developers familiar with our system and mentor them with it.

Our simple rule of “reviewing code before deploying it” has had a successful outcome in our development team. The next step for us would be to incorporate third-party code review tools and review templates to make our review processes more structured while keeping our review practice lightweight.

For more on code review, there are many good books and articles about the importance, effectiveness, applicability, and best practices of code reviewing as a part of software development process, including ‘Peer Reviews in Software: A Practical Guide’ by Karl Wiegers.

Happy reviewing!

(This post has been updated since it was originally written in 2015.)​