The original text and the translation
Why review code?
原 文 : Why review code?
A friend recently asked me why code reviews are so valuable. At least most Silicon Valley tech companies do a code review of every change to ensure that at least two people have seen it. In my previous job, we did code reviews selectively (and infrequently) until a new employee from Google came on and encouraged us to review all code — which we did. It turned out to be a good decision.
If you do code reviews the right way, it won’t bother you. You and the person reviewing your code are not adversaries, you are working together to build the best software. (The point is not to take feedback too personally — even if you have to change the code, it doesn’t mean there’s a problem. Getting feedback is normal because it helps you grow!)
Some companies have strict rules about how many people must review each piece of code and who must be assigned to each piece of code. I don’t think this is necessary at all, I prefer a simpler system where the only rule is that every piece of code is reviewed by at least one person. In fact, you still have to submit reviews to the people who maintain the code you change, but it’s better not to make it mandatory.
Here are a few reasons I can think of why code reviews are valuable. That’s a lot!
- The code itself. The most obvious value of code reviews is “finding bugs.” Or if you dig a little deeper and find some best practices or underlying rules the author doesn’t know about, you can feed them back to improve that specific code.
- Knowledge sharing at the macro level. When you review someone else’s code, you’re learning new techniques that will benefit you — and vice versa, it’s possible that someone else is reviewing your code and giving you better advice. If you can put what you have learned into practice, you will grow up to be an engineer.
- Knowledge sharing at the micro level. Mitigate the “bus factor” by increasing the number of people familiar with all the code. (The larger the bus factor is, the less likely the project will be affected by the loss of key people)
- Trend sharing. Code reviews, in turn, force you to communicate what you’re doing to your teammates, which ensures that you’re on the right track, rather than finding out days or weeks later that you’re on the wrong track.
- Communication practice. Clear communication is the most important skill for working successfully, both inside and outside the team! Code reviews give you the opportunity to practice writing more clearly, both when describing the purpose of a change and when submitting feedback. And with luck, the next time you need to write something “really important,” you’ll find yourself ready.
- Historical records. In my experience, if people know that what they write will be read, they write better submission description messages. This is very useful when reviewing old changes!
- Something to discuss. Sometimes when you want to agree to a change, you will find it difficult to verbally describe and express agreement on such details as specific algorithms. It is more accurate to communicate through a piece of code, because the code tends to be more explicit.
- Team cohesion. When code reviews become a regular activity, you feel more like a team working together, rather than everyone “on their own track.”
- Reading exercises. Practicing reading other people’s code will help you make your own code more readable (and therefore more maintainable). This will make you write better code later! If I have to make a choice, reasons 2, 5 and 6 are probably the most valuable to me.