Skip to content

Code Review Best Practices¶

Roadmap: https://roadmap.sh/best-practices/code-review

1. Purpose and Mindset¶

1.1 Code Review Purpose (catch defects, share knowledge, raise quality)
1.2 No One-Way Process (collaboration, not gatekeeping)
1.3 Continuous Improvement Over Perfection
1.4 Knowledge Sharing
1.5 Cross-Functional Knowledge

2. Before the Review (Author)¶

2.1 Changes Ready (self-review first)
2.2 Definition of Done
2.3 Adhere to Guidelines
2.4 Code Style / Best Practices Adherence
2.5 Document New Features
2.6 Proper PR Description (what, why, how)
2.7 Note Questions for Reviewer
2.8 Prepare List of Risks / Issues to Highlight

3. Before the Review (Reviewer)¶

3.1 Adequate Review Time (no rubber-stamping)
3.2 Learn Context and Requirements
3.3 Architecture Understanding
3.4 Impact of Change Analysis
3.5 Determine Review Level (deep vs shallow)
3.6 Complex Tasks Breakage (request smaller PRs)

4. During the Review¶

4.1 Quality of Code Overall
4.2 Consistency Everywhere
4.3 Change Functioning (does it actually work)
4.4 List Review Risks / Issues
4.5 Potential Issues (reviewer's perspective)
4.6 Potential Issues (author's perspective)
4.7 Failing Tests / Bug Detection
4.8 Re-run Tests to Verify

5. Giving Feedback¶

5.1 Clear Feedback
5.2 Professional Feedback
5.3 Positive Feedback with Criticism
5.4 Nitpick Comments (label as nit:)
5.5 Prioritize Feedback (must-fix vs nice-to-have)
5.6 Open Mind (Reviewer)

6. Receiving Feedback¶

6.1 Address Feedback Received
6.2 Address Author's Concerns
6.3 Author Feedback Welcomed
6.4 Open Mind (Author)
6.5 Implement Changes with Explanations
6.6 Conflict Resolution

7. Process and Workflow¶

7.1 Follow Guidelines
7.2 Document the Process
7.3 Pair Programming as Reviews
7.4 Encourage Participation
7.5 Collaborate (Reviewer ↔ Author)
7.6 Monitor Reviews (queue, blocked PRs)

8. After Approval¶

8.1 Merge Approved Code
8.2 Monitor Performance Post-Merge
8.3 Celebrate Success
8.4 Recognition and Rewards