Code reviews are an integral part of a developer's daily routine, ensuring the quality, correctness, and maintainability of the codebase. Whether you are requesting a review or providing one, adhering to best practices can significantly enhance the code review process. In this blog, we will explore some of the practices that I have been following.
Asking for a Review
Ensure Github Actions Pass: Before assigning a Pull Request (PR) for review, it's crucial to ensure that all Github actions have passed successfully. This basic requirement helps confirm that the new code doesn't break existing functionality and saves reviewers time.
Break Down the Code: For large Pull Requests, breaking down the code into multiple commits within the same PR can make the review process more manageable. This allows reviewers to focus on specific changes and understand them in isolation.
Detailed PR Description: Provide a comprehensive PR description, explaining what the changes are, why they are necessary, and the testing plans. A well-documented PR description helps reviewers understand the context and purpose of the changes.
Giving a Review
Gather Just Enough Context: In the initial review, focus on getting just enough context about the feature or issue without understanding the implementation from the author itself. This minimizes biases and increases the chances of identifying blind spots in the code.
Review the Code in Steps: Start by reviewing the entire code to get a high-level understanding of the changes. Then, dive deeper into specific functions or segments to identify performance optimizations, decoupling of code, and large functions.
Understand Testing & Deployment Plans: Before giving your approval, it's good to understand the testing plans for the feature. Ensure that the code has been adequately tested, covering both functionality and edge cases. At times when there are changes in different repositories that are dependent on each other or there is a certain production script to be run before merging the code, it's good to have an understanding of the plan to push the code to production.
Do a QA of the feature: Reviewing is more than just the code. Try testing the feature, validating the technical approach, and ensuring it meets product expectations.
Maintain a Priority List: I usually maintain a list of the PRs & the expected date of when the feature needs to go live. This helps me organize the reviews by priority. Next, when reviewing the code, understand which parts of the code are most critical and can lead to production issues. Those hot paths should be reviewed first. This approach helps ensure that the most important issues are addressed on priority.
Avoid Context Switch: To maintain focus and ensure thorough review, avoid reviewing multiple different features together in a single session. Context switching can lead to confusion and overlook critical issues.
Focus on Code Quality: Once the functionality is confirmed as correct, and any necessary performance optimizations are in place, comment on code quality. Address issues related to code structure, maintainability, and adherence to coding standards.
Suggest, Don't Instruct: When making suggestions or pointing out issues, use a constructive and supportive tone. Instead of instructing with phrases like "You should stop doing," opt for more collaborative language like "I think it would be better to." Avoid blameful or aggravating language.
As the reviewing engineer, remember that your approval is required before the code can be merged. This is a significant responsibility, as it ensures that the codebase remains robust and clean.