Every software engineer will do code reviews part of their day to day work. This process is central to the development process but is not discussed enough.
Before we dive into it, it is important to understand quality assurance processes and quality gates. What comes next is a summary from Andy Groves’s High Output Management Book. Highly recommended. On a factory line, production managers ensures quality in two major ways:
1) They test every single product out of the assembly line
2) They sample products from the assembly line and only stop the production line if the number of defects is high.
Two things to note. One is that quality gates slow down and increase the cost of production. Two is that the first process has a higher cost as we always need to check every single product whether there is a defect in it or not.
So why do companies do it? Because the cost of catching a defect early on far exceeds the cost of having a defect or needing to deal with it or recall it once it is in production.
Going back to code reviews, it falls into the first and more costly category where every code check-in needs to be reviewed. Considering that speed is such a competitive advantage in the software development process, it becomes an even more costly step.
Why do now software producing companies do it? For the exact same reason as the one mentioned above. In addition, they do it to ensure the code stays maintainable and readable for future check-ins. Keeping with the factory line analogy, it is like not only reviewing products from the assembly line but also reviewing the factory machines that produce the products. Another reason they do code reviews is that it provides a great opportunity for engineers to train other engineers and improve their skills.
What’s the best way to do it?
The way I go with it is that I throughly review interfaces, dependencies and decision that cannot be easily reverted. I also tend to be more thorough with new engineers joining the team. As for nits, suggestions, etc…, the best is to just mention them and leave them up to the main author on whether to implement them or not. This will make sure the developer is unblocked, will increase the team velocity and will ensure the code review process is friendly and fast.