Translation: Ethics Code Review

Recently, I came across a small but very capacious article by a single developer, in which he views the code reiew from a rather unexpected side. Most of the materials on code review talk about technical issues: what utilities to use, how to integrate code review into the continuous integration process, and other technical issues. The author also considers code review as social interaction. And, in my opinion, this is worth reading. Under the cut - translation.


Just as for many other things in our life, knowing why we are doing something allows us to do it really well and resist the desire to do it when it is not needed. To begin with, listing what code review is not :

• This is not half an hour a day of pleasant pastime when you shout at your colleagues and poke a finger at their mistakes. If you like to do code review to find other people's mistakes or lack of good practices in the code, then I have bad news for you - it seems that this is not the best thing for you.
• This is not a way to train your colleagues. If you think that the team should adhere to certain practices when developing, then you need to set aside time separately and coordinate these practices with the developers personally.
• This is not a place for discussion. Comments in the code review should be as short and to the point as possible. No attempt to defend their point of view or to defend their position.

In this scenario - why do we need code review? Based on my practice, I can identify four reasons:
')

1. This is a way to share responsibility . When we do a code review, we, figuratively speaking, “help pull the strap.” We abandon our usual "I am not @ # $%! @ #, Not my code" in favor of "well, we will bring down this dragon together."
2. This is a great way to learn from each other . At first glance, this paragraph is contrary to the second paragraph of the previous list, but take my word for it. During my career, I learned incomparably more of the new from friendly, non-aggressive discussions with colleagues, rather than from all these aggressive quibbles to my code from people who think they know everything better than anyone (or at least better than me). Moreover, I was never able to learn how to benefit from such comments, only a keen sense of hatred (for comments, not for people). No matter how much better you are, other people deserve respectful treatment. If only because you yourself were once so.
3. This is a way to find bugs and obvious errors. In a good way, this is the main reason for doing a code review. Looking through someone else's code, focus on finding errors and bugs that the author of the code could overlook - and suggest simple ways to fix them. Sometimes you will even encounter the same mistake repeated several times. Resist the temptation to write comments like “boy, why are you doing THIS again?!?”. Be professional. And if you think that some points in the code of your colleagues need to be discussed - do it personally, politely and without “raids”.
4. This is a way to improve the quality of the code . As I wrote, the best practices need to be discussed with colleagues personally. But if you find a place in the code that you think can be easily improved, it would be a good idea to politely suggest this as part of code review.

To summarize: you should always remember that your colleagues are professionals like you, regardless of the amount of personal experience. But more importantly, they are living people. And people work better and more productively and are happier when they are understood and respected. And code review can help with this - if used correctly.