What is Considered a Good PR Review?

Pull Requests (PRs) are an essential part of collaborative development, ensuring code quality, fostering learning, and maintaining project standards. A good PR review balances technical feedback with a positive, constructive approach that encourages both code improvement and team development.

Goals of a Code Review

1. Sharing Knowledge: PR reviews enable developers to share domain-specific and technical knowledge, enriching the skill sets of everyone involved.

2. Spreading Ownership: PRs prevent knowledge silos by encouraging multiple team members to work on different parts of the codebase. This fosters a collaborative environment where the entire team shares responsibility for maintaining the project.

3. Unifying Development Practices: Every developer has their own style, and PR reviews help standardize coding practices across the team. They promote discussions on architecture, design, and coding styles, creating a cohesive and unified codebase.

4. Quality Control: PRs ensure early detection of bugs, security flaws, and design issues. They make it easier and cheaper to resolve problems before they make it to production, thus improving the overall quality of the project.

Best Practices for Code Reviews

1. Decide on a Process: Establish a structured review process that the team follows, including draft states, feedback loops, and final approvals. This process helps streamline PRs and ensure that all aspects of the code are reviewed.

2. Focus on the Right Things: Prioritize high-impact elements such as functionality, software design, test coverage, and complexity. Automated tools should handle coding styles and formatting, freeing reviewers to focus on the code's quality and architecture.

3. Discuss the High-Level Approach Early: Before detailed code reviews, ensure that the overall approach and architecture are aligned. This reduces the likelihood of significant rewrites and ensures that the PR aligns with the project's goals.

4. Optimize for Team Performance: Fast, efficient reviews help the team iterate quickly and minimize context switching. Encourage small, frequent PRs for easier reviews and faster feedback.

5. Default to Action: Avoid delays in decision-making. If a review is stalled, approve it while flagging areas for future improvement. Keeping momentum is more valuable than achieving a perfect solution on the first try.

6. Keep Pull Requests Small: Break larger features into smaller, manageable PRs. Smaller changes are easier to review, reducing the chance of introducing defects and making the process more efficient.

7. Foster a Positive Feedback Culture: Frame feedback around improving the code rather than critiquing the person. Balanced feedback encourages collaboration and helps developers grow without feeling criticized.

8. Leverage Automation in Reviews: Use tools like Prettier, ESLint, SonarQube, and continuous integration (CI) pipelines to automate style, formatting, and security checks. This reduces the burden on reviewers and allows them to focus on logic and design.

9. Delegate Nit-Picking to Automation: Use automated tools to enforce consistent code styles, avoiding time spent on subjective preferences. For example, ESLint and Prettier can handle style enforcement, allowing reviewers to focus on substantive issues.

10. Communicate Explicitly: When providing feedback, be clear about what action is expected from the developer. Explicit communication ensures that changes are made correctly and avoids confusion.

11. Self-Review Before Submission: Developers should review their own code before submitting a PR, catching small mistakes and improving the quality of the submission. This saves time for reviewers.

12. Write Clear PR Descriptions: A well-written PR description provides context, explains what has changed, and highlights any special testing instructions. This helps reviewers understand the purpose of the PR quickly and reduces the need for back-and-forth questions.

13. Use Shared Repository Models: In a collaborative environment, using a shared repository model ensures transparency and facilitates easier reviews. It also helps developers understand the code’s broader context.

14. Keep Discussions Public: Keep all PR-related discussions in public forums like the PR comments section. This ensures transparency, helps team members who may have missed earlier conversations, and creates a record that can be referenced later.

Conclusion

A good PR review balances technical insight with constructive feedback, promoting both code improvement and team growth. By focusing on essential areas like functionality, design, and testing—and by leveraging automation to handle routine checks—PR reviews can ensure code quality and foster a collaborative, high-performing team environment.