Code Review Workflow
A comprehensive approach to reviewing code for quality, correctness, and maintainability.
Review Phases
Phase 1: Understand Context
Before looking at code:
- •Read the PR/commit description: What is this change trying to accomplish?
- •Check related issues/tickets: What was the original requirement?
- •Review the scope: Is this the right size for one change?
- •Identify the risk level: High-risk areas need more scrutiny
Phase 2: Correctness Review
Does the code do what it's supposed to?
- •Logic validation: Does the algorithm correctly solve the problem?
- •Edge cases: Are boundary conditions handled?
- •Error handling: Are failures handled gracefully?
- •Input validation: Is untrusted input validated?
Questions to ask:
- •What happens with null/empty input?
- •What happens at min/max values?
- •What happens on network/disk errors?
Phase 3: Security Review
Look for common vulnerabilities:
- •Injection attacks: SQL injection, command injection, XSS
- •Authentication/Authorization: Are access controls correct?
- •Sensitive data: Are secrets, PII, credentials protected?
- •Dependencies: Are there known vulnerabilities?
Red flags:
- •User input in SQL/commands without sanitization
- •Hardcoded secrets or credentials
- •Missing authentication checks
- •Overly permissive CORS/access controls
Phase 4: Performance Review
Will this code perform well?
- •Algorithmic complexity: O(n) vs O(n^2) vs O(n!)
- •Database queries: N+1 problems, missing indices
- •Memory usage: Large allocations, memory leaks
- •Caching: Unnecessary repeated work
Questions to ask:
- •What happens with 10x/100x the data?
- •Are there database queries in loops?
- •Is expensive work cached when appropriate?
Phase 5: Maintainability Review
Will this code be easy to work with?
- •Readability: Is the code self-explanatory?
- •Naming: Are variables/functions named clearly?
- •Structure: Is the code well-organized?
- •Duplication: Is there unnecessary repetition?
- •Tests: Are there adequate tests?
Questions to ask:
- •Would a new team member understand this?
- •If I see this in 6 months, will I know what it does?
- •Are the tests testing behavior, not implementation?
Giving Feedback
Be Constructive
- •Focus on the code, not the person
- •Explain "why", not just "what"
- •Suggest alternatives when criticizing
- •Acknowledge what's done well
Categorize Comments
- •Blocker: Must fix before merge
- •Suggestion: Would improve but not required
- •Question: Need clarification to understand
- •Nitpick: Style preference, optional
Example Feedback
Bad: "This is wrong"
Good: "This loop doesn't handle empty arrays - it will throw on line 15. Consider adding an early return: if (items.length === 0) return []"
Multi-Agent Review Strategy
For comprehensive review, delegate to specialized reviewers:
- •claude-code: Correctness, maintainability, tests
- •gemini-cli: Research, documentation, API design
- •codex-cli: Security audit, sandbox testing
Combine findings for complete coverage.