Code reviews

Code reviews are in my opinion one of the most important processes in development. I think it is along with setting up proper CI/CD pipeline most valuable thing for the bucks. On the other hand it is for me personally quite surprising how many companies are not doing code reviews at all or do them poorly.

Here is my sum-up of strongest benefits and some tip on the end of the article.

Benefits

They help to have better codebase (you don’t say). Developers are lazy in general and process that will force suggest them to check the code at least once more is certainly good. Developer that wrote code himself is probably hopefully most able to see and fix his mistakes. There is human factor involved as well, because to be honest you are probably more cautious about submitting the code when you know at least one other programmer will have to review it. And no one wants to look incompetent in the eyes of their coworkers by writing bad code.

They help for improving overall architecture and maintainability of application, especially when they are made by someone who helped to design application in the first place. Code reviews can surely catch some nasty bugs even before we publish code.

They help sharing of the knowledge between developers. So hopefully they can learn from each other, thus build better software for the company in the future. I personally love to work with more experienced developers because there are things that I can learn from them. And what is better for that purpose, than know what problem other programmer trying to solve and actually see the approach they used.

They help to build awareness among developers about other features and application parts. As result of this you get more flexible developers. They will probably feel more comfortable with switching tasks, for example in case that one of the developers will have to take sick leave or leave the company with unfinished work.

Tips

Code reviews cannot be done correctly if commits are huge. In this case they will be probably rushed, mainly because no one wants to or do not have enough time at once to go through hundreds of lines of code spread across different classes and files. Also there is decent chance that author already forgot what he was thinking when he was writing the code. So try to keep commits and pull requests reasonable small.

Do not dig too deep into details while reviewing the code. It is totally acceptable if you don’t find any issues with the code, actually it is best case scenario. Every developer has different style and meta when writing the code.

And don’t be rude in the pull request comments lol.

Leave a Reply

Your email address will not be published. Required fields are marked *