How to do code reviews effectively: Tips and tricks

Poorly set processes in software development can bring considerable damage to the company instead of the expected benefits. If you have read our previous article Code reviews: are they useful or a waste of time?, you already know that Code reviews are a part of the code review process, i.e. checking the quality of the code according to the agreed rules.

Code review occurs before the source code is deposited into the repository and is performed by a developer who was not involved in the coding of the code. It can include a wide range of activities from simply reading the code together with the author at one computer to team meetings where every line of code is discussed.

Both parties involved in a Code Review should be able to work together. The processes and criteria set for code review should be known in advance, otherwise there is a risk that the processes will drag on for a long time and tensions will arise between the two parties.

In this article, we will focus on streamlining code review processes, as well as tips and tricks for both the author and the reviewer.

General best practices

• If a software company defines code review as part of the Definition of Done (meaning the conditions that must be met for a task to be recognized as completed), it is essential to allocate the necessary time during planning. There’s nothing worse than not checking thoroughly under the time pressure of a looming deadline for developing the current version.
• The effectiveness of Code Review lies in minimizing the interactions between the two parties, as well as in reducing the time required for review. If an author gets something redone, the ideal is to have all the information available afterwards as to what needs to be changed for the next check to be successful.
• Communication between the reviewer and the author should be full of understanding and empathy. The goal is collaboration and joint identification of weaknesses in the code, not arguing about whose solution is better, or an association like, “He said my code is bad, so he’s actually saying I’m bad.”
• Code review does not check if the code will work. Only tested code is checked.
• The code check should not take more than an hour. If we’re involved in any activity that requires prolonged, maximum concentration, our performance starts to decline.

Code author – best practices

• By asking someone to look at your code, you’re not bothering anyone.
• It’s a good idea to run through your solution before code review and edit out the places that a reviewer might point out on review. After completing multiple quality code reviews, you’ll get a feel for where to focus your attention.
• Never take feedback personally, it’s the code that’s being evaluated, not your personality.
• The author should avoid extensive pull requests. It is advisable to send smaller, separately functional units for inspection. This not only speeds up the review process but also makes it easier to fix the code afterward.
• If the reviewer doesn’t like some parts of the code, try to get more information from the reviewer instead of arguing (or, in the worst case, guessing). For example, by asking “How would you code this part?” you can learn more about how to improve that part of the code.
• As the author of the code, you should take detailed notes, don’t expect to get them from a reviewer.

Reviewer – best practises

• He shouldn’t put off Code review because someone is waiting for him with the expectation that he’ll look at his code. This is why it is advisable to prioritize the Code Review, this will speed up the process and remove the frustration of waiting.
• At the beginning of a code review, it’s a good idea to make sure that the author understands that it’s not a personal attack if he gets something reworked, because there are good reasons to do so. for example rewriting two cycles into one for optimization.
• The reviewer is giving feedback and should phrase it in an optional style, i.e. that it would be good if the author had edited this or that. Not in the style that this still needs to be corrected by the author.
• The reviewer should focus more on the structure of the code than on individual lines. Code lines, even if written in a unique style, are relatively fine as long as they work. It’s worse when dealing with clumsy code prone to errors. Therefore, we recommend focusing your energy on the important parts of the code.
• It is better to look at the code you are reviewing alone first and form an opinion about it, and prepare questions for the code author if necessary. If we see the code for the first time in a joint meeting with the author we may be inclined to be influenced by the author’s advocacy.
• It never accuses the author of having done anything wrong. He may ask if there is any reason why he chose that option. If we see something we don’t like, it’s appropriate to phrase it as, “If I were doing it, I would…” and support it with a real example.
• The reviewer shouldn’t boast that they could have written the code in fewer lines and faster.
• It has to be specific. Feedback like “It could be done better” isn’t constructive, and the author won’t know how to turn it into better code. It is advisable for the author to take away notes on how to specifically improve things.
• If you need to change a large part of the code, it is a good idea to take the time to go through it with the author in person and answer all the questions.
• He should also praise everything that is not negative, or what is programmed, as we expect.

If you’re a Java developer looking for work, check out our employee benefits and respond to our job offers.

About the author

Jozef Wagner

Java Developer Senior

Viac ako 10 rokov programujem v Jave, momentálne pracujem v msg life Slovakia ako Java programátor senior a pomáham zákazníkom implementovať ich požiadavky do poistného softvéru Life Factory. Vo voľnom čase si rád oddýchnem v lese, prípadne si zahrám nejakú dobrú počítačovú hru.