The importance of code review

Some days ago someone wrote a super-wonderful blog post about the importance of selecting good programmers from mediocre groups. This article is really good, because it tells the situation and the terrible consequences, in my career I have seen too much, but it is very easy to prevent.

The author tells the reality that a company needs to implement a very important module, but at this point its senior developer Mr Senior is busy. So they gave the module to the novice Mr newbie--. He spent 4 months writing modules, two weeks to repair a lot of bugs found by QA, wasting technical support for countless hours to find bugs that QA didn't notice, and even causing customers to cancel the contract with the software full of bugs, and so on. Finally, the senior programmer stood up, took one months to rewrite from scratch, and then after the QA quick check, a nearly bug-free version of the release, everyone is satisfied.

The end is perfect, yes, but I don't know if you see it, but all the problems could have been avoided, as long as the company was able to introduce code review procedures in its daily development.

Now, before I explain how to avoid these problems, I want to describe what I think a good code review program should look like. All it needs to do is follow these two simple principles:

• No censored code is not in the master branch. Even a single commit, even the most advanced developer's code, is no exception.
• Everyone can review the code. Even the most junior programmers can participate.

These two principles seem counterintuitive. You might ask, "Why can't you trust high-quality code written by high-level programmers?" Or, "How do you believe that the code after the Novice programmer's review is OK?" ”

The first question should not be asked, because even the most senior and most advanced developers will make mistakes from time to time. While manual code reviews can never be as rigorous as automated testing and scripted manual QA, code review execution takes less time, and it's easy to spot problems that automation tests don't understand-often at the architectural level-which can be difficult to fix later.

As for the second question you don't trust the novice programmer-the answer is simple. It's always pleasant to have a pair of eyes to check the code, but that's not the main reason. What we really want to achieve is to improve the skills of junior programmers. At the time of the review, he was able to know how these advanced developers wrote the code. Most importantly, this will help him understand how to critically read someone else's code, and after two months he can even review his code to improve the quality of the code he eventually submits to the repository.

Now let's go back to the case mentioned by the previous author, and we can see that if Mr Newbie writes the code to be examined by Mr Senior, many of his initial errors will be found at the time of his first submission, and even he can consult and discuss the module with Mr Senior. Thus creating a better architecture may not be as good as the original 4 months to complete the task. In addition, Mr Newbie is aware of the need to go through the eyes of a senior developer, so he will be strict with himself when writing code, looking at his code critically. The most important benefit is that the whole process will teach Mr Newbie a lot about Mr Senior thinking, and perhaps wait until the next module is built, he has become Mr Intermediate (intermediate developer).

The importance of code review