Improve Efficiency With Smaller Code Reviews

In the ever-evolving software paradigm, oftentimes multiple developers work on the shared code base collaboratively. Code management becomes challenging with the number of developers, the scope of change, the pace of delivery, etc on a shared code base. The major challenges occur during:

1. Code Merge
2. Creating Code Reviews 
3. Performing Code Reviews
4. Tracking Deployment and
5. Debugging Issues Due to Code Changes

Irrespective of the nature of software architecture i.e. micro-service or monolith, these challenges can impact developers day to day productivity.  Creating a change set in chunks of smaller and related code reviews helps in mitigating the above issues as well as encourages collaborations and ensures a  healthy service. Let’s discuss the issue in detail and understand how using smaller code reviews can help mitigate these issues.

Code Merge

With the magnitude of deliveries made on a shared code base, code conflict, and branch diversion is highly possible. This could lead to hours of effort to rebase the branch with your local changes. In a shared code base where multiple developers are working, A code conflict due to a really large and impacting change could be time-consuming. This can be minimized by:

1. Frequent Code Merge: I usually prefer to merge the codebase a frequent intervals (daily or after any code merge that is related to files I am working on). This reduces the conflicts and makes it easy to merge. One can automate this by writing a simple bash script to perform git pull daily.
2. Small Code Reviews: Having small and concise code reviews will reduce the chances of code conflicts while merging. Even in case of a conflict, smaller code reviews are easier to resolve. The lower the number of files touched in a code review, the lesser the chance of conflict while merging. This will scale well with multiple developers working on a shared code repository.

Creating Code Reviews

Code review is another important aspect of the code lifecycle. This acts as a gatekeeper to capture potential issues and maintain a high quality of code. A code review is required for every change to implement 1. Feature release or 2. Bug Fixes. There is a tendency to create a large review for a major feature. These large changes could cause conflicts, bugs, multiple reviews, etc. To have an effective code review, it is always advisable to:

1. Create Small Reviews: Often large reviews are discouraging to the reviewer. A reviewer can get distracted by a large change set which could affect the quality of the review. Having a feature-focused or bug-focused review in a smaller size always encourages the reviewer to understand the change and review with attention. There are scenarios where it is difficult to segregate the change into smaller chunks of multiple reviews.
2. Segregate the Change: There are scenarios when smaller CRs are not possible for a particular feature. This feature could be impacting a wider range of functionality and so large number of files. In such scenarios, it is always better to segregate the changes into logical units. These units then deal with a particular aspect of the change and the reviews can be raised independently. Segregating a change in the logical unit will then help the developer to draw a clear boundary between changes and then later once all the related changes are merged, the final feature can be released.
3. Documentation: Documentation plays a very important role in understanding and maintaining the code base. This will also help reviewers in understanding the scope and details of the change and help them provide critical feedback. Documentation could be at various levels e.g. README file, Method, Class, etc. Proper documentation always raises the bar in code quality.
4. Testing and Details: Writing unit tests and maintaining the code coverage for any new code introduced or changed is always a good practice. This will help test current changes as well as ensure safety from any future changes. An integration test always ensures the functionality as a whole unit. It also captures any bug in end-to-end flow. It is always recommended to implement test cases and provide details in the code review.

Performing Code Reviews

Code review is another tool to ensure the quality of the code. This acts as a first guard towards any new change. To perform effective code reviews, there are various factors to be considered:

1. Understanding The Change: This can be articulated well by proper documentation and details to explain the scope of the change. The smaller the reviews the better the quality.
2. Small Code Review: The smaller the review, the more focused and traction a review can get. No one likes to review a long change set. Smaller reviews that are concise, well articulated, and segregated into logical units will help reviewers in spending quality time reviewing. This will also lead to a faster development and deployment cycle and minimize the possibility of any new bug in the change. Study shows that a reviewer is interested and perform a focused review when the size of the code review is small. It also helps the reviewer to engage and understand the change.

Tracking Code Changes

Having a smaller review makes it easier to track the deployment change, faster deployment, identify issues easily, etc. Once a review is done, the code flows through various stages to finally reach to production stage. With smaller changes, it is easier to track the application's behavior and identify the bug. This will also foster a faster deployment cycle in case of full CI/CD pipelines.

Debugging Issues Due to Code Changes

Imagine a situation where 10 files with 1000 lines of code changes are deployed in a single code change and some functionality breaks. The amount of time and effort spent rolling back the change, debugging the root cause, fixing, and ensuring something else is not broken will be tremendous. Usually, this not only hampers the productivity of the particular change set but impacts other change sets too. This can be controlled by creating smaller code reviews. With small code reviews, identifying a change causing the issue will be easy. Also, the reviews are segregated into logical units will provide more opportunity and control to developers to fix the bug easily without impacting other developers' changes.

I always encourage developers to segregate their large change set into smaller logical units and then work backward to raise smaller reviews, maintain a high bar in UT and IT, well document their changes, track pipeline, and merge code daily.