Code reviews are something I really value high. In my opinion, every software development team should do code reviews. In brief, the reason is learning and sharing knowledge and code quality. In this blog post, I will explain why.
Learning and Sharing Knowledge
This is maybe the most important reason to do code reviews. When you review your co-worker’s code you can learn both new programming techniques and how your software is programmed.
You might think that you will learn nothing new when doing code reviews. Think a moment when you have read some of your team’s code. Despite most of the time what we think of the code is “wtf”, there are also times when we think “Oh, I didn’t know it can also be done this way. I will use it next time!”. By doing code reviews you will see those good parts now and not later. That way you will also write better code next time. Programming techniques aren’t the only thing you can learn: you can also learn new libraries (for example NuGets in C#). Those libraries can be either internal or external libraries.
By doing code reviews you know how your software is programmed and thus you will know more about it. You don’t have to ask others all the time how does some module work if you have done some code reviews for it earlier. Gradually your team will know more about your software while doing code reviews. You will be more familiar with classes, libraries, coding conventions, etc. Without code reviews, you won’t learn that much or at least it would take much more time.
Often we might think beforehand that managers don’t want us to do code reviews because it takes time. One explanation for them is that code reviews will reduce the bus factor. Think of your super programmer to change a workplace suddenly. If code reviews have been done, others can continue from where he left much easier than if code reviews were not done. And why not to share super programmer’s knowledge to others via code reviews and develop more super programmers.
Don’t think that only junior developers will learn in code reviews because anyone can learn in code reviews. Maybe mostly it is a junior developer who will learn from a senior developer, but it can be also vice versa. I have learned a lot when reviewing junior developer’s code. They can have new knowledge that senior developers haven’t learned because they have been too busy to learn. Even if senior developers won’t learn, they will teach junior developers and that is valuable because that way the whole team will improve.
Better Code Quality
In my opinion code reviews are the second best way to improve code quality, while unit tests are best (combine both to have the best quality!). According to SmartBear’s The State of Code Review 2017 code reviews are the best way to improve code quality. Here is my ordered list why code reviews improve code quality:
- You don’t dare to write bad code when you know someone else will review it,
- The reviewer will notify you if there is a code one doesn’t understand and you will fix it and
- There will be fewer bugs because some of the bugs will be found and fixed already in code review.
Every developer has written bad code, and we will also in the future. But if we do code reviews, we simply will work more for the quality of the code because we know that someone else will read and “judgment” it. This gives us a good little pressure to write better code that others can understand.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (Martin Fowler)
Before you give your code to a reviewer, it is a good practice to pre-review your code by yourself. There you will fix the code before the review. For example, you will find commented-out code and remove them. This will already improve your code, even before it is actually reviewed.
Many times fewer bugs are mentioned as pros of code reviews. For example, an article in www.visualstudio.com from 2016 says that developers think finding defects is the main reason to do code reviews. My experience is that seldom you find bugs in code reviews. I can remember only few times when I found a bug as a reviewer or a reviewer found a bug in my code. But both have actually happened to me! That time when the reviewer found a bug in my code I was really happy because I was able to fix it immediately. The sooner you find the bug, the cheaper it will be to fix. If you find a bug in code review it is much cheaper to fix it immediately, than to find the bug in testing or worse, in production.
Fixing a bug today costs less than tomorrow.
Increased Collaboration
Believe or not, code reviews socialize developers. They force you to communicate with others. They force you to talk about the code under review with others.
Code reviews also give a proper place to get and give a feedback. Some developers don’t dare to ask for feedback about their code. If you do code reviews, there is a certain place to get feedback. For example, you can ask from the reviewer: “I am not very happy with this method. Do you have any ideas to make it better?”.
It is not only about getting feedback; if you are a reviewer, code review is a good place to give feedback. Usually, this is the situation when a reviewer is more experienced than a programmer, but not always. Without code reviews, there is a bigger chance to forget to give feedback. (Remember to give also positive feedback!)
“I Don’t Have Time to Review”
This is probably the most common reason to not do code reviews. In the short term, it is true: code reviews take time and sometimes you have to wait for the reviewer to review your code. There are times when code reviews make development process slower.
Think of good things about it that I wrote. You will miss all those if you don’t do code reviews. Are you too busy to write not to write good quality code? Are you too busy not to teach each other? Are you too busy not to collaborate with each other? Are you too busy to take risk of extra bugs? Are you too busy to share your code with others? I am not that busy and I hope you are neither. (See also my earlier blog post Too Busy to Improve?)
Conclusion
Code reviews will improve your code quality and knowledge sharing a lot. If your team isn’t doing code reviews I strongly recommend to do. I have experienced how much code reviews have improved software quality and shared knowledge.
In the short term code reviews take time. But in my opinion, they will pay back in the long term, or probably sooner in the medium term.
In this blog post, I concentrated on why you should do code reviews. In my next blog post, I will write about how you should do code reviews (ie. code review best practices).
Lassi Autio's Software Development Blog 
2 thoughts on “Why You Should Do Code Reviews? (Code Review 1/3)”