My take on Code Review #
If someone asked me for a one sentence summary on what code review is, I would say:
Code review is a technical process with cultural implications.
Well, that’s the fancy way to say it. All I want to say is that code review needs to be understood as part of the culture of your team, and not just another technical procedure for engineers to deliver code safely.
What does code review mean? #
Why don’t we start with Google engineers’1 take?
Code review is a process in which code is reviewed by someone other than the author, often before the introduction of that code into a codebase. Although that is a simple definition, implementations of the process of code review vary widely throughout the software industry.
It’s clear that the concept is easy to understand, but when we start to implement it, the process is more complex than we think.
I strongly suggest you to read chapter 9 of the book Software Engineering at Google – Although it’s long and it took me some time to finish and process the information, it’s worth it.
Tip: Beware that this article was written by Google engineers, so although there are some valuable takeaways, not everything may suit you or your organization.
Now let’s go to what we all came here for Why code review?
Why code review? #
First things first, I like to do it, period. Ha! Jokes aside, throughout my career I really got into code review. It was not just something that was needed from me, I actually liked to do it. You can learn and share knowledge by reviewing code.
For me, the best reason to do it is Code Correctness2. This is more than just checking if the lint or tests are passing!
Engineers are going to look at that new piece of code to see if it will be maintanable in the long run; if new dependencies are being introduced and/or breaking changes that we need to inform the user; if the new code is following the language and team guidelines.
Also, junior engineers have the chance to review and have their code reviewed by their peers, creating the opportunity to share knowledge that I mentioned before.
It’s interesting that in different parts of the book, they share that following guidelines previously agreed upon by the organization, is one of the key points to be able to handle the giant codebase that Google has!
All of this is correctness!
Many reports point to the efficacy of code review in the prevention of future bugs in software. […] The investment in the time for code review saved time otherwise spent in testing, debugging, and performing regressions, provided that the code review process itself was streamlined to keep it lightweight. This latter point is important; code review processes that are heavyweight, or that don’t scale properly, become unsustainable.
Yeah! Let’s keep it light and steady, shall we?
This chapter of the book has a lot of great things to cover, so expect to see more of it here.