Review Dimension Checklists
Detailed checklists for each review dimension that reviewers follow during parallel code review.
Security Review Checklist
Input Handling
- All user inputs are validated and sanitized
- SQL queries use parameterized statements (no string concatenation)
- HTML output is properly escaped to prevent XSS
- File paths are validated to prevent path traversal
- Request size limits are enforced
Authentication & Authorization
- Authentication is required for all protected endpoints
- Authorization checks verify user has permission for the action
- JWT tokens are validated (signature, expiry, issuer)
- Password hashing uses bcrypt/argon2 (not MD5/SHA)
- Session management follows best practices
Secrets & Configuration
- No hardcoded secrets, API keys, or passwords
- Secrets are loaded from environment variables or secret manager
- .gitignore includes sensitive file patterns
- Debug/development endpoints are disabled in production
Dependencies
- No known CVEs in direct dependencies
- Dependencies are pinned to specific versions
- No unnecessary dependencies that increase attack surface
Performance Review Checklist
Database
- No N+1 query patterns
- Queries use appropriate indexes
- No SELECT * on large tables
- Pagination is implemented for list endpoints
- Connection pooling is configured
Memory & Resources
- No memory leaks (event listeners cleaned up, streams closed)
- Large data sets are streamed, not loaded entirely into memory
- File handles and connections are properly closed
- Caching is used for expensive operations
Computation
- No unnecessary re-computation or redundant operations
- Appropriate algorithm complexity for the data size
- Async operations used where I/O bound
- No blocking operations on the main thread
Architecture Review Checklist
Design Principles
- Single Responsibility: each module/class has one reason to change
- Open/Closed: extensible without modification
- Dependency Inversion: depends on abstractions, not concretions
- No circular dependencies between modules
Structure
- Clear separation of concerns (UI, business logic, data)
- Consistent error handling strategy across the codebase
- Configuration is externalized, not hardcoded
- API contracts are well-defined and versioned
Patterns
- Consistent patterns used throughout (no pattern mixing)
- Abstractions are at the right level (not over/under-engineered)
- Module boundaries align with domain boundaries
- Shared utilities are actually shared (no duplication)
Testing Review Checklist
Coverage
- Critical paths have test coverage
- Edge cases are tested (empty input, null, boundary values)
- Error paths are tested (what happens when things fail)
- Integration points have integration tests
Quality
- Tests are deterministic (no flaky tests)
- Tests are isolated (no shared state between tests)
- Assertions are specific (not just "no error thrown")
- Test names clearly describe what is being tested
Maintainability
- Tests don't duplicate implementation logic
- Mocks/stubs are minimal and accurate
- Test data is clear and relevant
- Tests are easy to understand without reading the implementation
Accessibility Review Checklist
Structure
- Semantic HTML elements used (nav, main, article, button)
- Heading hierarchy is logical (h1 → h2 → h3)
- ARIA roles and properties used correctly
- Landmarks identify page regions
Interaction
- All functionality accessible via keyboard
- Focus order is logical and visible
- No keyboard traps
- Touch targets are at least 44x44px
Content
- Images have meaningful alt text
- Color is not the only means of conveying information
- Text has sufficient contrast ratio (4.5:1 for normal, 3:1 for large)
- Content is readable at 200% zoom