How do you code review?

How to Conduct an Effective Code Review

A code review is a structured conversation that improves quality, knowledge-sharing, and team health. Here's a practical, end-to-end framework to adopt:

1. Prepare the Review Environment

• ·Choose a platform (e.g., GitHub PR, GitLab MR) to centralize comments and track history.
• ·Run automated checks first (CI pipeline, linters, static analysis, unit-test coverage).
• ·Sync to the latest base to ensure you're reviewing the code that will actually merge.
• ·Set a timebox (30-60 minutes per 200-400 LOC) to prevent fatigue.

2. Scope the Review

• ·Understand what problem the change solves by reading the issue/ticket description.
• ·Check if the change is self-contained and follows the single responsibility principle.
• ·Look for related changes elsewhere that may affect behavior.

3. Review Passes

Conduct multiple passes focusing on different aspects:

• ·Functional correctness: Does the code do what it claims? Check unit/integration tests and logic errors.
• ·Readability & maintainability: Is the code understandable weeks later? Check naming, function length, and control flow.
• ·Performance & scalability: Does it meet non-functional requirements? Check for inefficient loops, batched heavy operations, and caching strategies.
• ·Security: Are there vulnerabilities? Check input validation, authentication/authorization, and hardcoded secrets.
• ·Test coverage: Is the change protected by tests? Check unit tests, integration/e2e tests, and code coverage.
• ·Documentation & API contract: Is the change well-documented? Check docstrings, changelogs, and READMEs.
• ·Style & conventions: Does it blend with the codebase? Check linting, formatting, and language idioms.

4. Writing Feedback

• ·Be specific and actionable.
• ·Separate 'what' from 'why'.
• ·Group related comments.
• ·Prioritize (blockers, critical, minor).
• ·Use a respectful tone.

5. Closing the Review

• ·Address comments.
• ·Re-run CI.
• ·Approve/request changes.
• ·Follow the team's merge strategy.
• ·Verify the change lands cleanly post-merge.

Review Checklist

✅ Functional

• · Meets acceptance criteria
• · New code paths are tested
• · No lint errors

📖 Readability

• · Descriptive naming
• · Functions ≤ 30 LOC
• · Complex logic documented

🚀 Performance

• · No O(n²) loops
• · Heavy operations batched/cached
• · No premature optimizations

🔐 Security

• · Input validated/escaped
• · No hardcoded secrets
• · Authorization checks present

🧪 Tests

• · Unit tests for new code
• · Integration/e2e tests for public contract changes
• · Acceptable code coverage impact

📚 Docs

• · Public API changes reflected in docs
• · New behavior in changelog/release notes
• · Inline comments for unclear intent

🎨 Style

• · Passes linter/formatter
• · Consistent indentation
• · Follows language idioms

Tips for Reviewers & Reviewees

• ·Keep PRs small and incremental.
• ·Provide context and explanations for intentional design choices.
• ·Respect reviewer bandwidth and prioritize feedback.

By following these steps and adapting the checklist to your team's conventions, code reviews become a reliable safety net rather than a chore.