Our code works after a middle-of-the-night hotfix…do you still need reviews?
If you are newer to programming or work for companies that don’t do reviews, you may be wondering why code reviews are so critical.
This question is more likely if you already have automated testing or a QA (Quality Assurance) team. Code reviews are necessary as they offer multiple benefits that help improve your code and your team. These benefits include:
- Helping reduce bugs and logic errors
- Providing an opportunity for training
- Spreading knowledge across areas and teams
- Revealing new ideas and techniques
Let’s take a closer look at each of these.
Code reviews help reduce bugs and logic errors.
One of the main things a reviewer should be looking for when reviewing code is that the code does the right thing without any errors.
I can’t tell you how many times a reviewer saved me the headache of debugging an issue by pointing out bugs they found during a review. I was very thankful to them.
It may seem like it would be hard to find bugs while reading code, but as developers become more experienced reviewing code, issues will start to stand out.
Even with QA and automated testing, finding bugs during a code review is helpful.
Take a second to think about a project with automated testing but no code reviews. How do you know a test is correct if you do not review the code? It is all too easy to make the same mistakes in automated tests as actual code.
Reviews help verify the code and tests are both correct.
A code review can direct the developer to the exact area of the problem, making it easier to debug and fix.
Would you rather have to work through a vague bug report to reproduce a bug or a reviewer point you to the exact line of code that is an issue? It is harder to debug off of a bug report. When we get a bug report, a user is already affected by the problem. I don’t know any developers who like fixing urgent user bugs.
Reviews are just one more step we can use to help avoid stressful after hour bugs.
Reviews offer opportunities for training.
We all know how quickly the technology around us changes. It isn’t that much of a stretch to say that there is a new language, tool, or framework every day. We also learn new best practices, standards, and ways to do things as we gain more experience.
There is always something new to learn.
How do you keep all the developers on your team up to date with these changes?
Of course, there are courses, tutorials, blogs, your team wikis, and guides out there. Developers should continue to use these resources and learn from them. But do you have time for every developer on your team to always go through a course?
Are they going to remember everything from them?
I can honestly say the most I have ever learned about writing good code has come from code reviews.
I have taken many great courses, got a computer science degree, and stayed up to date with many blogs and resources. However, none of these resources have come close to what I learned by working with my team and having my code reviewed.
I have to credit my team’s reviews for any high-quality code I write today.
I honestly learned more in a few months from code reviews than I did through years of courses. There are a lot of fantastic resources that do a great job of teaching software development. But they have to cater to a massive audience and can’t cater their lessons to your project, code, and your skills.
Code reviews are excellent at addressing these flaws.
Code reviews will focus on your team’s code and workflows while naturally raising areas you need to improve.
You will get feedback on your code for specific things you may need to practice or research more. When I notice the same comments coming up in reviews, I’ll read more about the topic or work with one of my peers that I know are experts on that topic. Other times the comments are enough to learn what I need to without additional resources.
Learning from code reviews is a natural result of effective review comments.
In addition to learning from comments on your code, just reading another developer’s code is a great way to learn.
Reviewing another developer’s code will show you new ways of approaching problems, how different developers architect and design features, and expose you to various packages, tools, and technologies.
Seeing how other developers code is one of my favorite things about performing code reviews. I’m often inspired to go back and use things I see developers doing in reviews in my code.
Code reviews spread knowledge across areas and teams.
If you had two teams of developers who always worked together and reviewed each other’s code versus two groups of developers who never reviewed the other team’s code, who do you think will have better code in the long run?
It probably will be the teams that review each other’s code. Those two teams will be passing knowledge back and forth about their specific areas and the best way to do things. They will be learning from different experiences and projects.
It’s essential someone familiar with the project still reviews the code, but getting someone from outside the team as a reviewer only helps.
Cross-team reviews are a great way to expose all team members to these different areas and spread specific learnings across all teams.
Depending on the size of your company, you may have many different teams and applications. Or maybe you have a complex application with a team that not everyone gets a chance to work in every application area. Developers across different projects don’t always get to work together.
If someone on team A introduces a better way to do things or experiments with a different design pattern, team B usually doesn’t get this knowledge.
Even if team A announces their new way of doing things, team B may not adopt it or realize its value.
When team B can review the code, they can see exactly how it works and the value it can bring.
Or maybe they would get other ideas and be inspired to try something else or help improve team A’s design. Plus, no one from Team A has to realize this should be shared or remember to make an announcement.
Team B will naturally see it during its code review.
Code reviews are one of the only ways to share knowledge naturally across multiple teams.
Code reviews also reveal new ideas and techniques.
Reviews will teach the same team new things the same way they will teach multiple teams. But new ideas and techniques often come up in code reviews even among the same team members.
Think about most of the code you write. How often do you research different design patterns, consider different architectures or attempt multiple solutions before deploying code? If you are anything like me and many of the developers I work with, I’m guessing this isn’t that often.
We do an excellent job of going through these steps for more complex features and new projects but don’t often feel the need to do this for our standard everyday features.
At most places, we don’t have the time to pair program on everything or always meet about how to code every feature.
You can get some of these same benefits from code reviews.
The reviewer may suggest an improved design or ask a question that leads to a better plan. They make these suggestions without taking the time to pair program or schedule a meeting. Once a team implements a review process, these suggestions happen without extra steps.
Code reviews make some of the benefits of pair programming, and design meetings naturally occur for every piece of code without special steps.
Putting up small and focused PRs help get this feedback quicker.
You can ensure everyone can move quickly by getting feedback in small iterations. Small and quick reviews let the author know they are on the right path early and often. When reviews are practical and efficient, developers can often avoid massive rewrites.
Think like running your code reviews like your agile sprints.
If you care about code quality, you need code reviews.
It doesn’t matter what processes you already have in place. QA, automated testing, or acceptance testing is not a replacement for another developer reviewing your code. Code reviews are not a replacement for the other processes either.
For high-quality, bug-free code, we need all these processes.
If you liked this and would like to see other tips, advice, and articles from me, you can find me on most social media under @kevinhickssw.
Top comments (0)