dcsimg

WEBINAR:
On-Demand

Virtual Developer Workshop: Containerized Development with Docker


Introduction

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 Checklist

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.

Peer Review

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.

Capture Metrics

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.

Code Readiness

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.

Conclusion

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!



About the Author

Tapas Pal

I am working in Microsoft Technology for last 15 years and presently working with Cognizant Technology Solutions, India as Senior Architect. I have completed TOGAF 9.1,Microsoft Certification on .NET 1.1 , .NET 2.0, SQL Server 2005 and Sharepoint. Please visit my Blog - http://tapas-pal.blogspot.com/

Related Articles

Comments

  • Collaborator

    Posted by Justin Collier on 01/29/2018 08:38pm

    Nice article! Full disclosure, I'm the product owner at SmartBear for our Collaborator product. I'm excited that you referenced it. I wanted to chime in on Checklists. You're right about their importance and thought I would share some tips. - No more than 10 items in the list - No obvious stuff - Nothing that can be automated - Include easy to forget items - Use empirical evidence to build the list - Replace stale items

    Reply
  • You must have javascript enabled in order to post comments.

Leave a Comment
  • Your email address will not be published. All fields are required.

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date