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 : 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. Ensure Github Actions Pass : 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. Break Down the Code : 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. Detailed PR Description Giving a Review : 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. Gather Just Enough Context : 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. Review the Code in Steps : 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. Understand Testing & Deployment Plans : Reviewing is more than just the code. Try testing the feature, validating the technical approach, and ensuring it meets product expectations. Do a QA of the feature : 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. Maintain a Priority List : 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. Avoid Context Switch : 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. Focus on Code Quality : 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. Suggest, Don't Instruct 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. Also published . here

How to do Code Reviews

Too Long; Didn't Read

@shlokashah

RELATED STORIES