Skip to Content

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