Let’s meet halfway – getting & giving better code reviews
Code reviews are part of any software development environment. Not the most pleasant part, in what a developer is concerned, since it involves his/her work being scrutinized and it may feel stressful, “but it’s also one of the best ways to get feedback on your code, to catch typos and mistakes, and, more broadly, to grow as an engineer”.
In order to take some unnecessary pressure out of this process, there are tips & tricks synthesized in the online media that help both code developers and code reviewers make the best out of this stage. We asked a few collegues here at LASTING Software to help us select a few best practices/rules/recommendations.
Let’s review some of them, starting with the most quantifiable ones.
5 practical rules for code review
A developer should review less than 400 lines of code at once;
Keep the inspection rate at a density of less than 500 LOC per hour;
Try not to surpass 60 minutes at once without taking a break, if you want to keep a high performance;
Establish tangible, measurable goals for the entire process;
Use code review procedures that can be followed and tracked (checklists, collaborative tools, fixing processes to be implemented).
(Selected from Best Practices for Code Review, as presented by SmartBear)
5 recommendations for developers
Prepare a quick summary where you explain the problem and the proposed resolution;
Auto-review, prior to someone else reviewing your code, so you can trim some of the problems yourself;
Communicate – by using annotations to highlight all the soft spots, and tag the right people involved in the project that might clarify these problems you feel you need a second opinion about;
When the reviews are back, remember the importance of team work and concern yourself with their utility and processing prior (and over) feeling anxious;
Refactor changes without altering behavior.
5 recommendations for code reviewers
Always keep in mind the code purpose and the project scope;
Ask clear questions whenever the functions and classes reason does not reveal itself;
Be clear when highlighting the problem you have identified, and propose alternative solutions;
Write the reviews in a neutral and concise manner and avoid absolute judgments;
Don’t forget to mention the good things you notice – keeping it clear you review with the overall quality in mind, not just to hunt the errors.
You may find more useful advice, examples, and technical guidelines related to code reviewing in our third source of inspiration for this article – on Medium.