Requesting Code Reviews
Quick Start
- Self-Review - Review your own diff first, catch obvious issues
- Prepare Code - Tests pass, no debug code, documentation updated
- Write Description - Clear summary, changes list, testing info, screenshots
- Select Reviewers - Match expertise to changes, respect workload
- Time Appropriately - Early week, morning hours, avoid Fridays
Features
| Feature |
Description |
Guide |
| Self-Review |
Catch issues before requesting |
Check debug code, TODOs, test coverage |
| PR Description |
Guide reviewers effectively |
Summary, changes, testing, attention areas |
| Reviewer Selection |
Match expertise to needs |
Code owner, domain expert, security reviewer |
| PR Sizing |
Optimal size for review quality |
<400 lines ideal, split larger PRs |
| Timing |
When to request reviews |
Morning, early week, check availability |
| Reviewer Guidance |
Help reviewers focus |
Key areas, skip suggestions, questions |
Common Patterns
# PR Description Template
## Summary
[What changed and why - 2-3 sentences]
Resolves #123
## Changes
- [Bullet point each significant change]
## Testing
### Automated Tests
- [x] Unit tests added/updated
- [x] Integration tests pass
### Manual Testing
1. [Step to verify]
2. [Expected result]
## Screenshots
[For UI changes]
## Areas Needing Review
- Security: [specific file/concern]
- Performance: [specific concern]
## Checklist
- [x] Self-review completed
- [x] Tests pass locally
- [x] Documentation updated
# PR Size Guide
| Size | Lines | Review Time | Recommendation |
|------|-------|-------------|----------------|
| Small | <100 | 15-30 min | Ideal for quality review |
| Medium | <400 | 30-60 min | Acceptable |
| Large | <800 | 1-2 hours | Consider splitting |
| Too Large | 800+ | 2+ hours | Split required |
# Reviewer Selection
1. Code owner - maintains affected area
2. Domain expert - knows the technology
3. Security - for auth/crypto changes
4. Architecture - for design changes
Max reviewers: 4 (too many = diffused responsibility)
# Self-Review Checklist
[ ] No console.log/debug statements
[ ] No commented-out code
[ ] No hardcoded values (should be config)
[ ] Error handling appropriate
[ ] All tests pass
[ ] New code has tests
[ ] Complex logic has comments
[ ] Commit messages clear
[ ] Rebased on latest main
Best Practices
| Do |
Avoid |
| Self-review first |
Submitting PRs without testing |
| Keep PRs small (<400 lines) |
Creating massive PRs |
| Write clear descriptions |
Leaving descriptions empty |
| Highlight key review areas |
Expecting reviewers to find everything |
| Choose reviewers wisely |
Overloading single reviewers |
| Be responsive to feedback |
Ignoring reviewer availability |
| Include screenshots for UI |
Rushing reviewers |
| Test thoroughly first |
Wasting reviewer time on broken code |
Related Skills
receiving-code-reviews - Handle feedback professionallyfinishing-development-branches - Complete PR preparationverifying-before-completion - Pre-submission verificationwriting-plans - Plan review-ready deliverables
