Code review has been there for a while. But many people struggle to explain why they are doing it in the first place. It’s like a default action, that is required for mystical “good code quality”. Yes, it’s fairly simple to justify to yourself or other people why you and your team need code review. But often these reasons don’t really have solid proof of effectiveness. Or just doesn’t work when a team doesn’t meet even their standards of code review quality and involvement.
I’m going to talk about one real and universal reason why you personally should review the code of your teammates. Also, I’ll share a small example and a study related to this reason.
Why do people review code in general?
Let’s enlist common reasons to review code changes. These are:
- Check security issues
- Implementation check
- Architectural review
- Code style review
- Performance review
- Errors and bugs and mistakes catching
- Maintainability, changeability
- Knowledge sharing
All of these reasons aimed to mitigate “future issues”. Improving code quality helps the application to run with fewer bugs and performance issues. And better code quality brings joy for developers — good code easier to read and maintain :)
So these reasons mostly aimed for better code quality. That’s great. But what in the code review for you personally? The last line in the list is “knowledge sharing”. Usually, this means “senior devs help less experienced folks write better code”. But what about just reading?
The ultimate reason to review the code
Well, reviewing teammates’ code makes you more familiar with the codebase. And thus making you more satisfied with the code quality! Apparently, how people perceive the “code quality” is not only measured by the complexity of this code but also by how people are familiar with the code. Familiarity plays a big role in our acceptance of the code.
Devs, who review code more often, tend to evaluate their codebase more “quality” than those who review less. A team might have several similar codebases in terms of code quality. But perceive the code which they simply didn’t work very often as “bad code”.
Studies and examples
You can watch an interesting story about code familiarity and code quality perception. The speaker tells a story about the team, which has several codebases. The team evaluate one codebase as “good”, and another as “bad”. But after code complexity analysis, turns out that the codebases are pretty similar code in terms of quality and complexity. But the good code is the code on which the team worked daily, and the bad code is the code they inherited from another team in the organization, and thus have no familiarity with it.
Also, as mentioned in this research, devs who are satisfied with code review (and perform it more often), usually more satisfied with their codebase. And those, who are satisfied with the code review process, tend to do code review more often than those who didn’t.
Code review is better for you. And you don’t need to go deep into the code.
So, the reason for you to read code is (at least) to track changes and “index” codebase. It’s not necessary to dig into the details of each, especially when the codebase is enormous. But reading to have at least the idea of code structure can improve your feeling about the whole codebase. It’s a great way to not be sad about code quality in the future :)