This blog series has covered multiple facets of development standards, from code quality and documentation to configuring virtual and containerized environments. In the previous blog, we discussed the benefits of code reviews to ensure your organization is delivering high quality, optimized, and secure solutions. In this blog, I am going to discuss best practices for performing code reviews at your organization to optimize reviewer time and increase review quality.
Code Review Best Practices
Code reviews can be performed in different formats and at different development checkpoints such as pull requests, deployments, and releases. Some organizations specify which format to use (i.e. in-person, unsupervised, or team review) and how often they occur (i.e. per feature, pull request, or release). Ideally, work with your team to determine what checkpoints make sense to validate your project’s requirements and optimize the team’s time. Your team may want to perform in-person reviews as they are a great way to discuss and work through issues together. Alternatively, they may request “unsupervised” reviews where the reviewer gives feedback via comments in the code repository without an actual meeting. The following code review best practices are recommended regardless of the format or interval that your team chooses to follow.
Review Individual Changes
As part of code reviews, a reviewer looks at another colleague’s code and gives feedback on the individual sections of code that have changed. The easiest way to perform this style of code review is during pull requests, when a new feature has been developed and is ready to be merged with the rest of the codebase. At this point, a reviewer can look at all of the changes that were made to produce this feature and identify any security concerns or quality inconsistencies with the rest of the codebase.
In some situations, it makes sense to perform code reviews of releases. That is, a group of features are all ready to deploy to test, stage, or production, and your team wants to review all of the changes in this release. Release reviews are great, especially as a quick scan for issues, but if your organization does code reviews this way, make sure you also have a method to review smaller changes. Reviewing large scale changes makes it harder to ask questions about the code (e.g. Why was this added? Where is this used?).
Provide line by line feedback
I recently had a developer comment that they appreciated when I gave feedback on individual lines of their code. By reviewing the individual lines, I was able to ask the developer specific questions about things such as variable naming, method calls, and performance optimization. When prompted with these questions, the developer and I could work together to make sure the code was the most understandable and used code quality best practices. Providing line by line feedback enabled both myself and the developer to come up with new consistency rules for the codebase as well as learn more about what standards are necessary and how we could adapt our internal standards for each language and framework.
Pull the code down and test it
Code reviews can cover multiple aspects of the development workflow from code quality to validating documentation. One of the best ways to validate documentation is for the reviewer to test the codebase. If your team has followed the process recommendations in part 3 of this series, then it should be straightforward for a code reviewer to pull down the code and test the setup locally. In my experience, this is a great way to determine if documentation is easy to follow as well as start conversations around configurations and setup steps. If a reviewer cannot run the solution, configurations may be missing or more information could be added in order to streamline the process.
Configure Pipelines for Automatic Checks
Pipelines enable developers to add automatic processes to the code repository that can run whenever new code is added or under review. Remember the code quality tools we mentioned in part two of this series? Pipelines are a great way to ensure that beautifiers and linters run against a project and report any errors. Additionally, these pipelines can run build scripts, unit tests, and security checks to validate that the solution compiles, passes all existing tests, meets a testing coverage requirement, and follows all security guidelines. Anything that can be automated should be automated as part of the code review process to allow reviewers to focus on providing additional feedback.
Add Merge Checks to the Repository
Developers can add merge checks to the codebase in order to ensure that all quality requirements are met before new code is merged with the core repository. Merge checks report out the status of pipelines, discussed above, and allow your team to configure additional requirements. Below are some example merge checks.
- Did the codebase build successfully?
- Did the codebase meet the code coverage requirement for tests?
- Are all comments and conversations resolved?
- Did all (or a specific number) of the reviewers approve the merge/pull request?
- Are all tasks associated with the merge/pull request completed?
Code reviews cover a lot, from code quality to validating tests and documentation. Similar to creating pipelines to automate checks, merge checks hold your team accountable to the standards put in place without requiring a manual review.
Conclusion
We recommend using the above approaches in order to ensure that your code reviews are comprehensive and validate code quality and security. If you are interested in learning more about development standards, the benefits they can bring to your organization, and the best practices for implementation, here are the rest of the blogs in this series.
If you have any questions or want to discuss how your organization can implement development standards into your projects, reach out to us!