Throughout my career, I’ve had the privilege of having my code reviewed by many talented developers, which has helped me gain a deeper understanding of code review. To further refine my skills, I also delved into various books and articles on the subject. Based on my experiences as both a reviewer and a reviewee, as well as my research, I’ve identified several core concepts that I believe are essential for effective code review. In this post, I’ll share my insights and personal take on these concepts.
Understand the problem being solved
Before starting the review, refer to any documentation you have about what the code is supposed to do and make sure it’s clear. Having precise requirements is crucial for assessing whether the code performs its intended function.
Start with what you know
If you have a Merge Request with numerous modified files, examine if there are any files that are uncomplicated to review, and start with those. Gitlab incorporates checkboxes into the interface that enable you to indicate the files you have already assessed, and other tools may have comparable features.
Go in chronological order
Starting from the chronological beginning of the code can help you comprehend the sequence of events. However, in configuration code such as Terraform, this may not be as straightforward.
Make sure the code is doing what it says it does
Ensure that the code performs the tasks that its names imply. Are the classes, functions, and variables functioning as intended? Does the overall code align with the specifications, designs, or acceptance criteria? If you are uncertain about what the code is doing or if it adheres to the standards, do not hesitate to ask for clarification. If the code is perplexing to you, it is probable that others will also find it baffling.
Could these changes break existing functionality?
Where does this code get invoked or how is this infrastructure used? Could these changes have adverse affects?
What will happen for edge cases?
For example, if a function accepts a null value, will it handle that properly?
Try it out if you can
Running code locally while reviewing a Merge Request offers multiple advantages. It helps to detect conflicts with the existing codebase, identify potential issues, assess the code’s functionality, and provide more comprehensive feedback to the developer. Additionally, testing code locally can reveal performance concerns or resource utilization issues, ensuring that the code meets the required quality standards before merging it into the main branch.
Build a custom code review checklist
Creating a custom code review checklist can significantly improve the code review process’s efficiency and effectiveness. Here are some steps to build a custom code review checklist:
- Analyze previous code reviews or production issues to identify common patterns or recurring issues.
- Prioritize the most critical issues or those that have had the most significant impact on the system or product.
- Develop a checklist that includes these issues or patterns, and any specific areas of concern for the project, team, or technology stack.
- Refine the checklist based on feedback from the team, incorporating any additional items or removing any that are redundant or not applicable.
- Continuously iterate and improve the checklist as new issues emerge, and the team gains experience and expertise.
By following these steps, you can create a concise, focused, and practical checklist that addresses the most critical issues and areas of concern for your project, team, or technology stack.
Take the time to read and understand every line
Devote sufficient time to scrutinize and comprehend each line of code. While a high-quality code review can be time-consuming, the outcome is more maintainable and less error-prone code. If you encounter a statement that is unclear, research it, and then inquire with the developer for clarification if it remains confusing.
Fault Tolerant 