Translation: Ethics Code Review

Original author: Marco Troisi
  • Transfer
Recently, I came across a small, but very capacious article by one developer, in which he considers code reiew from a rather unexpected perspective. Most of the code review materials talk about technical issues: which utilities to use, how to integrate code review into the continuous integration process, and other technical issues. The author considers code review as a social interaction. And, in my opinion, it is worth reading about it. Under the cut - translation.


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

  • This is not half an hour on the day of a good time when you shout at your colleagues and poke a finger at their mistakes. If you like to do a code review to find someone else’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 educate your colleagues. If you think that the team should adhere to certain practices during development, then it is necessary to separately allocate time and coordinate these practices with the developers personally.
  • This is not a place for discussion. Comments in the code review should be as short as possible in the case. No attempt to defend your point of view or defend your position.


In this situation - why then need a 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 to pull the strap”. We are abandoning 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 contradicts the second paragraph of the previous list, but take my word for it. During my career, I learned incomparably more new things from friendly, non-aggressive discussions with colleagues than from all these aggressive nit-picking to my code from people who think they know everything better than everyone (or at least better than me). Moreover - I never managed to learn how to benefit from such comments, only a sharp sense of hatred (for comments, not for people). No matter how much better you are, other people deserve self-respect. If only because you yourself were once like that.
  3. This is a way to find bugs and obvious errors. In a good way, this is the main reason to do a code review. When looking at someone else’s code, focus on finding bugs and bugs that the code author might have overlooked - and suggest simple ways to fix them. Sometimes you will even encounter the same mistake repeated several times. Fight the temptation to write comments like “guy, 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 “hitting”.
  4. This is a way to improve the quality of the code . As I already wrote, best practices need to be discussed with colleagues personally. But if you find some place in the code that you think can be easily improved, it would be a good idea to politely suggest this as part of the code review.


To summarize: you always need to 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.

Also popular now: