Effective code reviews: 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: 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 code review tips and tricks for both the author and the reviewer.

Code reviews 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 the author is given something to rework, it is ideal to have all the information afterwards about what needs to be changed to make the next review successful.
• Communication between the reviewer and the author should be full of understanding and empathy. The goal is to collaborate and jointly identify weaknesses in the code, not to argue about whose solution is better, or to make an association like “they said my code is bad, so they’re 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 review. 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 them instead of looking for arguments (or, in the worst case, fighting with them). 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 practices

• The reviewer shouldn’t put off a code review because someone is waiting for feedback. It’s advisable to prioritize the code review, as 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 their code requires revisions, 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 tone, such as suggesting that it would be good if the author made this or that change – not in a demanding tone that implies this needs to be corrected by the author.
• The reviewer should focus more on the structure of the code than on individual lines. Individual lines, even if written in a unique style, are relatively fine as long as they work. It’s worse when dealing with clumsy code that is 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 explanation.
• The reviewer should never accuse the author of having done anything wrong. They may ask if there is any reason why they 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.
• Feedback has to be specific. Comments like “It could be done better” aren’t constructive, and the author won’t know how to improve the code. It is advisable for the reviewer to provide 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 their questions.
• The reviewer should also praise everything that is done well, or what is programmed correctly as expected.

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.