Code review is a process to ensure that code is readable and maintainable; it meets the functional requirements, ensures that the team knows the code base, catches bugs, enables developers to adopt the best coding practices, and finally, improves the software quality. A code reviewer will review the source code of an application and report the findings to the developer. During the code review session, a reviewer will focus on general unit testing, comment and coding conventions followed, error handling code written, memory leaks, use of threads, control structures, code performance, functionality implemented, and securities.
Based on my industry experience, I would like to share the following best code review tips and practices a reviewer can follow for an effective code review.
The Code Review Process
The code review process starts when a developer finishes his work on a feature and checks code into a repository. Before code check-in, the developer has to ensure a successful code build and unit testing results are green. Once pushed in the code repository, the developer will create a review request and assign it to another developer from the same team for peer review. After the reviewer finishes commenting on the code and the developer makes all necessary modifications, the developer will merge the modified code into the main development code repository branch. An additional external code review process could be initiated after internal peer review. It’s suggested that all developers follow the above-mentioned review practice to keep reviews as simple and painless as possible.
Plan Review Sessions
Before the actual code review, the developer should plan and set the objective of the review session. For an effective code review, they should discuss with the development team how the feature should be built. Approach senior developers from the team who have worked on the code base before to decrease the risk of a code review.
Review checklists are important for both reviewers and authors; without a checklist, if the author forgets a task, the reviewer is likely to miss it also. A checklist will confirm that authors and reviewers review all components of code and record issues and defects against each checklist. You will start making fewer errors.
Use Code Review Tools
Identifying the right code review tool is very important, and there are several types of code review tools available in market. Use CodeCollaborator; it’s a lightweight code review tool that optimizes the time that your team spends in review.
Short Sessions of Code Review
It’s a best practice to split the code review process into sessions and take numerous breaks. An hour of code review session is usually effective. As a reviewer, try to break your tasks written in the checklist into smaller subtasks and review smaller and more manageable chunks of code.
Review a Maximum of 400 Lines of Code
As a reviewer, it gets pretty difficult to review more than 200 lines of code at once, and the reviewer should never exceed reviewing 400 lines of code during a review session to ensure quality. Take breaks during longer code reviews sessions.
Before external reviews, make sure you fix all findings from internal peer reviews. The peer review process is a type of review in which a document and code are examined by their author and one or more colleague from the same team to evaluate its technical content and quality.
Design and UI Review
During a code review session, the reviewer should start with design document and changes the developer has to complete to incorporate as per design. Most reviewers just review code and give feedback; they often forget how the application would look in a browser or the devices where the code is intended to execute. It’s recommend for reviewers to spent extra time to review the UI design by checking how the user interface looks and whether all the changes mentioned for UI relate to the expected functionality.
Document Code Review Comments
Make sure, as a reviewer, that you document all code review comments properly, either in an e-mail, Word document, or an Excel worksheet. If you are using an organization standard review tool, add your review comments there and communicate them to developers/authors. As per the Capability Maturity Model Integration (CMMI) level process, an organization has to maintain code review documents in a central repository. The code review document helps developers cross check the highlighted issues and avoid making similar mistakes in the future.
Following are some metrics that should be captured during a review:
- Time in review: This metric determines how much time a developer has spent on code review.
- Defect count: How many defects were found during the code review session.
- Percent of code reviewed: It calculates the percent of code reviewed per developer.
- Code Coverage: The code coverage is the proportion of the code reviewed.
Prior to each code review session, every developer should scan their code for common mistakes, check if enough tests were written for automatic review, and verify that their code was written according to the relevant style guide. Get the latest version of the code in development environment and let the continuous integration server check every new chunk of code after its submission by running a series of previously written automated tests. The reviewer should start review only if the code passes those tests successfully.
I hope the these code review tips help code reviewers and developers perform better code reviews going forward. Reviewers can be hard with developers, pointing out many things that are incorrect or could be improved, but the code review process should always be pursued in a constructive way to gain maximum benefit.
Code reviews are immensely important and a vital part of the development process; they improve the software quality and help software developers to enhance their skills continuously. Happy reading!