Ask a Question

Wintertainment 2020 - Day 4: Five Things To Do in 2021 to Improve Your Code and Document Reviews



Hi everyone! Today's discussion will be about improving code and document reviews - we have prepared a lot of great insights you should take with you to 2021!


Share your thoughts in the comment section below and answer the questions at the end of the article. We are excited to know what you think on the topic! Those who provide the most insightful comments will get the chance to win prizes from SmartBear! See participation rules and event schedule


Let's go!


5 Things To Do in 2021 to Improve Your Code and Document Reviews 


One of the ways we can improve is through learning from other people. In our annual State of Code Review report, we surveyed over 700 fellow software professionals, asking what they thought about best code and document review approaches.  


Here are five valuable takeaways we got from them. 


1. Daily code reviews are key.


In our most recent State of Code Review report, we’ve found that satisfied teams perform code reviews on a daily basis, compared to teams that are dissatisfied. Though some developers feel that code review is disruptive to their productivity, many see it as an opportunity to not only improve the code base, but to reduce bugs, train junior team members, and increase knowledge across the team. 


2. More tool-based reviews, more code satisfaction. 


There are several types of approaches to code review. Many teams utilize more than one of the approaches to meet their needs based on the immediate situation. The approaches include tool-based, ad-hoc (or “over the shoulder”), and meeting-based reviews. Based on the findings in the State of Code Review report, we highly recommend conducting tool-based code reviews.  


Your team is more likely to be satisfied with your code-review process, and subsequently more satisfied with your overall code. If you’re a developer on a team that needs additional budget, or managerial approval to make this possible, share the report with them, or this case study in which a company reduced their code- and test-review timeline by 70%.  

3. Code reviews need clear guidelines.  

The clearer you can set expectations, the more likely your team will produce higher quality software. This applies to both code and document reviews.   

How can you ensure that your team is clear on expectations? First, define and assign responsibilities to team members. Second, outline them in a checklist for both code and document reviews. Code-review tools like Collaborator let you build custom checklists in review templates, so participants with different roles and responsibilities can easily see what’s expected of them on each project.  


4. Pull reports to get insights on how to improve.  


It’s hard to be satisfied with your code-review process when you can’t track its aggregate effectiveness. Teams that do review reports and key performance indicators, are more likely to know what to improve when making changes.  


As an example, tracking the types of defects found, and their severity, can provide insights to help you in process improvement. Adopting a tool that enables you to track key metrics and pull custom reports on peer code reviews is the fastest way to improve your process 


5. Code review does double duty in training new people.  


In the most recent State of Code Review report, we’ve found that teams that use code review for onboarding and training are twice as likely to be satisfied with their code reviews. Teaching and learning are critical to keeping us engaged. Whether you’re a senior engineer or new to the team, you have something to offer or can learn something new. Code review can be a vehicle for knowledge sharing as well as daily learning. When your team is learning and collaborating on a daily basis, they’ll build trust and improve your code quality at the same time.  


Further Reading 


This was just a glimpse of the insights that you can access by downloading the full State of Code Review report. If you prefer watching instead of reading, catch up on the webinar recording instead. Want to hear even more useful tips straight from your peers? Then check out the quotes we received from community members all over the world in What Makes for a Great Code Review? 


What do you think? Comment below!   


Wed love to hear about your experience in this area. Share it with the Community: 

1. How often does your team put out a new release? 

2. What prevents your team the most from getting a release out on time? 

3. How often do you participate in code reviews? 

4. What do you think are the most important benefits of code review? 

5. What do you think is the number one thing a company can do to improve code quality? 

Looking forward to seeing your comments. 

Community Hero

I'll talk about my last job because we had better processes there than my current one.


1) Releases to Prod could be months apart because customers really didn't want things changing on the fly.  We had 1-2 releases a year.  We did have an internal environment that we treated as our Prod and everything that got through QA was deployed there.

2) Last minute change requests from management.

3) As often as I could.  Devs got used to inviting me once I got them to see that it helped me too.

4) Education for the group.  We all knew what was going on in the code and the different points of view were helpful.

5) Encourage communication.  Discourage information silos.

Community Expert

We release code "when it's ready". This happens approximately once per week, sometimes more often.


We have effectively two silos: the back-end team and the front-end team.

The back-end team does regular code reviews, using tools provided in gitlab. Everything in this article applies: every MR, tool-based, guidelines, tracking, training. As an SDET I also participate. The amount of bugs is minimal, and the code is consistent across all microservices.

The front-end team has no official code review process. There are bugs. And the code is inconsistent between different projects, leading to frustration from developers when they are asked to help out elsewhere.


I think the direction for improvement is clear.


My spin on the code review is "test code" based.

Yes, SDET, QA, test engineers, etc., should be involved in the production code reviews so they have a better understanding of how to ensure the changes made meet the requirements.
This is also true of your test code, Follow the same process, Extra sets of eyes may see areas for improvement or a possible issue someone may have over looked.

Community Hero

1. How often does your team put out a new release? 

Currently every month our client is releasing out to production.


2. What prevents your team the most from getting a release out on time? 

Most common is any change in sprint tasks in last days of sprint.


3. How often do you participate in code reviews?

Not more but sometimes like 1-2 tickets in 1 cycle for Automation test cases.


4. What do you think are the most important benefits of code review?

  • With the help of Code review, can maintain consistent coding style across the company.
  • Also Team member can get better understanding of code base and can learn for one another.

5. What do you think is the number one thing a company can do to improve code quality? 

  • Peer review is the important thing a company can take into consideration to improve code quality
  • Best code practice training with-in the teams can also help.