Why Code Review in smartnut.ru?
Hi, Habr! I am one of the team of developers of SmartNut, a web-service for small companies engaged in support and it-outsourcing. We are proud of what we do and no less than how we do it. I want to share with you a real life story on the topic of code review.
All the people inside are perfectionists. If you do not see this in a person, then this does not mean at all that this is not in a person. Perhaps he has an ideal order at home, although he does not write the code well. The other way around, can keep order in the code or in the car, but somewhere to connive in relation to itself.
However, the easiest way to find a perfectionist in relation to others. It’s very easy to demand perfect work, of course, if you yourself know how to do it well.
The programmer Vasya wrote lines of code, checked them. Perhaps he wrote some tests, and maybe he did not. After that, with peace of mind, commit to the common repository. After some time, other programmers, studying the code of the new revision and seeing what Vasya wrote,opened their veins and made hara-kiri came to Vasya and opened his veins and made themselves hara-kiri telling what was wrong and how it could be done better. Vasya meekly agreed, everyone was satisfied, but the code remained as it is, because was already commited and possibly tested. And errors were corrected on it.
Many of us are familiar with eXtreme Programming practitioners. One of them is pair programming. From experience, it is very difficult to fully use this practice - it is difficult to give up “personal space”, it is difficult to “sell” this practice to the authorities (“programmers will work twice as slowly!”), Etc.
But you can start eating the elephant in parts. The first part is code review!
')
Programmer Vasya completed the task. In order for a task to be considered completed, it must be passed through the code review column on our scrum board.
Thus, we:
And so that there are no questions “who should conduct a Code Review?” We have the person on duty to carry out this procedure on each iteration.
We do not use any additional tools for the Code Review, but always sit down together and review the changes.
Using some tools in this case will only slow down the process. If you are in the same room, then there is no need to engage in email-ping-pong - it is much easier and more understandable to explain everything with words, but it is better to show it. In addition, personal communication is much more useful for the development of each employee and for the team as a whole.
So we do smartnut.ru and wish you the same.
Be flexible, friends, and see you soon!
All the people inside are perfectionists. If you do not see this in a person, then this does not mean at all that this is not in a person. Perhaps he has an ideal order at home, although he does not write the code well. The other way around, can keep order in the code or in the car, but somewhere to connive in relation to itself.
However, the easiest way to find a perfectionist in relation to others. It’s very easy to demand perfect work, of course, if you yourself know how to do it well.
How our process looked like before
The programmer Vasya wrote lines of code, checked them. Perhaps he wrote some tests, and maybe he did not. After that, with peace of mind, commit to the common repository. After some time, other programmers, studying the code of the new revision and seeing what Vasya wrote,
As it became
Many of us are familiar with eXtreme Programming practitioners. One of them is pair programming. From experience, it is very difficult to fully use this practice - it is difficult to give up “personal space”, it is difficult to “sell” this practice to the authorities (“programmers will work twice as slowly!”), Etc.
But you can start eating the elephant in parts. The first part is code review!
')
Programmer Vasya completed the task. In order for a task to be considered completed, it must be passed through the code review column on our scrum board.
Thus, we:
- we get code analysis by another programmer before the commit;
- improve the design of the code;
- we transfer knowledge at an early stage;
- We get rid of a number of obvious errors that are invisible to Vasya's purposeful eye.
And so that there are no questions “who should conduct a Code Review?” We have the person on duty to carry out this procedure on each iteration.
We do not use any additional tools for the Code Review, but always sit down together and review the changes.
Using some tools in this case will only slow down the process. If you are in the same room, then there is no need to engage in email-ping-pong - it is much easier and more understandable to explain everything with words, but it is better to show it. In addition, personal communication is much more useful for the development of each employee and for the team as a whole.
So we do smartnut.ru and wish you the same.
Be flexible, friends, and see you soon!
Source: https://habr.com/ru/post/133016/
All Articles