Four Code Review Process Strategies
We are sometimes asked, "What is the best configuration for my code review process?" That topic has even been debated internally at Seapine. There is no right way, but there are pros and cons to the different approaches. You might consider the following four strategies and determine what is best for your specific business needs.
Review by File Owner
In this approach, each code file is assigned an owner who is an expert in that area. Every code change made to that file is reviewed by the owner regardless of what feature the code change belongs to. The file owner can create a code review container and conduct the code review at their convenience, regardless of whether the feature has been fully implemented. The advantage of this approach is that the reviewer is more likely to catch issues specific to that component and take ownership to keep that code file clean. For example, the owner would more easily identify newly added methods that duplicate existing functionality, misuse of a lock or mutex, incorrect usage of a specific library or toolkit, or not following UI or database standards. The disadvantage of this approach is that the file owner might not see the bigger picture for the feature and how the changes interact with other components.
Review by Feature
In this approach, each feature or requirement is assigned a code reviewer. Every code change made as part of that feature is reviewed by a single person regardless of what code file is modified. The code review container is generally created and code reviews conducted once the feature is fully implemented, but the reviews could be done in smaller chunks if the feature has multiple sprints or milestones. The advantage of this approach is that the reviewer will fully understand the feature from top to bottom. For example, they would more easily identify poor flow of information between components or data that is gathered at the UI level but not saved to the database. The disadvantage of this approach is that the reviewer is not an expert in some areas of the code and might not catch component specific bugs.
Review Both Ways
If quality is critical, you could approach code reviews both by file owner and by feature. All code changes made for a feature would be reviewed by a single feature code reviewer and potentially by multiple file owners (depending on how many code files were modified). From a quality perspective, this incorporates the advantages of both review approaches above. The disadvantage is higher cost since time spent on code review activities is doubled.
If you have certain files that are especially important and some features that are especially important, then you could consider a hybrid of the review by file owner and review by feature. In this approach, only critical files are assigned a file owner, which means only those files go through a review by file owner. Critical files may have characteristics such as a requiring high speed/scalability, low tolerance for bugs, or brittle code that often breaks when modified. Similarly only a subset of features goes through a code review. Features may be considered critical based on visibility, contractual obligations, or consequences of functionality failure. An advantage of this strategy is lower cost since less time is spent on code reviews, yet all critical changes are still reviewed. The disadvantage is that some code changes are reviewed twice (critical files modified as part of a critical feature), while other changes are not reviewed at all.
Surround SCM Features
If you are using Surround SCM, functionality is available to support any of these code review approaches. Here are some Surround SCM features you may want to take advantage of in your code review process. If you need help configuring these in the way best suited for your company, Seapine's professional services team would be happy to assist you.
- Code Reviews – Surround SCM has built in code review containers that manage the review process.
- Custom Fields – File owners can by identified via a custom field. The field format of the custom field should be SCM User, which automatically includes all Surround SCM users in the field's dropdown list.
- Triggers - File owners can be notified by email if a file they own has been modified and needs to be reviewed. Configure a trigger to send an email to the user identified by the Owner custom field.
- Add to Code Review from History window – Highlight a file in the Source View window and then select the History command to display the file's History window. Then highlight a range of file versions and select the Add to Code Review command to populate a code review container.
- Workflow states – When using the review by file approach, one way to track which versions have been code reviewed is via workflow states. Configure a trigger to change the state to Needs Review each time a file is modified. Each time the user perform a code review, they can review all changes since the last file version with a Reviewed state. After the code review is completed, change the file's state to Reviewed.
- Filters – Setup a filer to easily see files you currently need to review. The filter criteria might have Owner set to <current user> and state set to Needs Review.
- Code Review Coverage Report – This report identifies what code changes have not yet been reviewed.