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

• Unit tests added/updated
• 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

• Self-review completed
• Tests pass locally
• Documentation updated

PR Size Guide

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 professionally

• finishing-development-branches

• Complete PR preparation

• verifying-before-completion

• Pre-submission verification

• writing-plans

• Plan review-ready deliverables