Checklist
This doc covers what to look for during a code review on the high level.
Pre-Review Preparation
Understand the PR’s context
- Read the PR description and related issue tickets.
- Verify that the PR is not overly large (consider asking for it to be split if needed).
Ensure clarity
- Ensure the description clearly articulates the problem and solution. If either is unclear, ask the author for clarification before deep-diving into the review.
Review Process
Functionality & Requirements
- Does the code solve the right problem?
- Does the implementation match the business requirements?
- Are all edge cases considered?
- Is there backward compatibility, or is it clearly explained why it is not needed?
Code Readability & Maintainability
- Is the code clear and understandable at first glance?
- Are functions, variable names, and types descriptive and self-explanatory?
- If complexity is unavoidable, are comments or documentation added for clarity?
- Is tech debt tracked with a TODO comment and Jira story? For example:
Testing & Quality Assurance
- Are there unit tests covering all logic? Consider if code should be restructured to prevent excessive mocking.
- Are there integration tests to verify the whole system works together? These should be minimal since business logic is already covered by unit tests.
- Are the tests failing when they should (i.e., do they actually catch issues)?
- Are non-happy path scenarios covered (negative tests, edge cases)?
Security & Data Handling
- Does the code introduce any security vulnerabilities (e.g., SQL injection, XSS, CSRF, information disclosure)?
- Is user input sanitized and validated properly?
- If handling sensitive data, is encryption or secure storage used where necessary?
- Are permissions and authentication properly enforced (for APIs, database access, etc.)?
- Are there feature flags in place for experimental or risky changes?
Performance & Scalability
- Are database queries optimized with indexes, joins, and limits?
- Does the code handle large-scale data efficiently (e.g., pagination, batching)?
- Does the code minimize unnecessary API calls or network overhead?
- Are background tasks and concurrency handled safely (no race conditions, deadlocks)?
Coding Best Practices
- Is error handling implemented correctly?
- Are there appropriate logging and metrics in place?
- Does the code use appropriate design patterns?
- Are third-party dependencies necessary and well-justified?
PR Etiquette & Communication
- Does the PR have a clear, well-written description? If necessary, does it include a post-deploy test plan?
- Are changes isolated and not mixed with unrelated modifications?
Final Steps
- Differentiate between mandatory and optional feedback (e.g., “Nitpick,” “Consider,” or “Blocking issue”).
- If there are no blocking issues, approve. Improvements can be made in follow-up PRs.
- Re-review promptly once updates are made and avoid unnecessary back-and-forth discussions.
Additional Best Practices for Code Reviewers
- Be respectful and constructive – Focus on the code, not the developer.
- Provide explanations for your feedback – Don’t just say “this is wrong,” explain why.
- Make concrete suggestions – Whenever possible, include sample code with your suggestion.
- Ask questions instead of making assumptions – If something seems off, ask for clarification.
- Highlight good practices – Acknowledge well-structured code and improvements.
- Balance thoroughness with speed – Don’t delay PRs unnecessarily. Aim for less than one business day turnaround.
Last updated on