The Value of Code Reviews

The lack of value that companies place on code reviews has always been a bit of an enigma to me throughout my software development career. As a mobile consultant for the last eight years, I have seen inside the development lifecycle of numerous organizations and not once has creating a pull request, or how they conduct a code review been included in the onboarding process; both are always an afterthought. I want to talk about why I think the process of conducting code reviews should be an integral part of every developer's workflow.

First, lets talk about why we should be placing a higher value on code reviews. This is the best way for new developers to get acclimated with the codebase. They will learn the preferred style guidelines, design patterns, and code structure. This all happens by allowing the reviewers to reference the ticket being worked on and what code is being touched. A few other benefits of poking around in pull requests are seeing how accessibility is being handled throughout the application as well as localization. These are two topics for another day, as they are often overlooked as well, but learning how these are done early on in the development process really instills that they should be a natural part of your workflow moving forward. Regarding experienced developers on the project, reviewing pull requests encourages developers to see other sections of the application that they may not be actively working on which allows them to have a broader understanding of the application itself. There are many times where one developer becomes extremely knowledgeable in one portion of the app yet out of the loop in other areas. This hurts long term when developers come and go from projects. Lastly, having as many developers as possible reviewing the pull requests will dramatically reduce regression.

A few things I suggest to accomplish the why mentioned above:

• Always write a small summary and/or description about what has changed and why.
• If the pull request modifies the user interface, attach screenshots that capture what has changed so the team can verify changes while examining the code.
• Require multiple approvals on each pull request.
• Find a good way to collaborate when doing code reviews.
• Strongly request the other developers to pull down the pull request to their local machines and do their own testing and verification.
• Piggy backing on the point above, developers should do their own QA; I cannot stress this enough. QA should not be wasting time doing all the testing for developers.
• Developers should set aside one hour per day to review pending pull requests.
• It is important to emphasize the value of code reviews ⎯⎯ early and often.