Sophie Alpert
Translator: UC International research and development Jothy
Welcome to the “UC International Technology” public account, we will provide you with the client, server, algorithm, testing, data, front-end and other related high-quality technical articles, not limited to original and translation.
Recently, a friend asked me why it is important to do code review. 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 review selectively (rarely) until a new Google employee came on the team and encouraged us to review all code — which we did. It turned out to be a great decision.
If you code review the right way, it won’t bother you. You and your Reviewer are not opponents; you are working together to build the best software possible. Don’t worry too much about feedback — 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 have strict owners for 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 has to be reviewed. In practice, 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 why I think review is important. That’s quite a lot!
-
The code itself. The most obvious value of Code Review is “finding bugs”. Or if you dig a little deeper and find cases of best practices or potential rules the author didn’t know about, you can feed them back to improve the specific code.
-
Knowledge sharing at the macro level. When you review someone else’s code, you’re learning useful new techniques – and vice versa, it’s possible that someone else is giving you better advice when reviewing your code. If you can put what you’ve learned into practice, you’ll make a great engineer.
-
Knowledge sharing at the micro level. Mitigate the “bus factor” by increasing the number of people familiar with all the code. (Translator’s note: The larger the bus factor is, the less likely the project will be affected by the loss of key people)
-
Trend sharing. In turn, code Review forces you to communicate with your teammates about what you’re doing and gives you a chance to roll back, which ensures you’re on the right track.
-
Communication practice. Clear communication is the most important skill for working successfully, both inside and outside the team! Code review gives you the opportunity to practice writing clearly, both when describing the purpose of the change and when submitting feedback. And with any luck, the next time you have to write something “very important,” you’ll find yourself already prepared.
-
Historical records. In my experience, people write better commit messages if they know that what they write will be read. This is very useful when reviewing old changes!
-
Something to discuss. Sometimes when you want to agree to a change, you find it difficult to verbally describe and express agreement with the details of a particular algorithm. It is more accurate to communicate through a piece of code, because the code tends to be more explicit.
-
Team cohesion. When code review becomes a regular event, it feels 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 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 important to me.
英文原文
React author’s in-depth issue on Hooks worth reading
UC International Technology is committed to sharing high quality technical articles with you
Please follow our official account and share this article with your friends
