Code Review (Part 1): Where and Why in the SDLC

Code review is a quality and collaboration practice: someone other than the author looks at the change before it's merged. When done well, it catches bugs, improves design, and spreads knowledge. This post explains where it fits in the SDLC and how to make it effective.

Where code review sits

Code review belongs in the implementation phase, as a gate before code is considered "done" and before it reaches testing (and later deployment). In flow:

Developer implements a feature or fix.
Developer opens a pull request (or equivalent).
One or more reviewers comment and approve (or request changes).
After approval, the change is merged and enters CI/testing and eventually deployment.

So review is part of "definition of done" for implementation: no merge without review (unless you have a rare, explicit exception).

Why do it?

Catch bugs and design issues: A second pair of eyes finds logic errors, edge cases, and design problems before they hit tests or production.
Consistency: Naming, structure, and style stay aligned with team standards.
Knowledge sharing: Reviewers learn the codebase; authors get feedback and learn from suggestions.
Security and compliance: Sensitive code paths get an extra check; audit trails (who approved what) support compliance.

What to look for in a review

Correctness: Does the code do what the requirement/ticket says? Are edge cases and errors handled?
Design: Is it clear, maintainable, and aligned with existing patterns? Any unnecessary complexity?
Tests: Are there tests for the new or changed behavior? Do they add value?
Security and performance: Any obvious risks (e.g. injection, sensitive data) or performance pitfalls?
Style and consistency: Linters often handle style; review can catch what tools miss and reinforce norms.

Focus on the most impactful feedback; avoid nitpicking that doesn't change behavior or maintainability.

Making review effective

Small changes: Smaller PRs get reviewed faster and more thoroughly.
Clear context: Good description, link to requirement/ticket, and "how to test" help reviewers.
SLAs: Agree on how quickly reviews should happen (e.g. within one day) so authors aren't blocked.
Culture: Frame feedback as improvement, not blame; authors and reviewers are on the same team.

Summary

Code review is a quality gate in the implementation phase, before merge and before testing/deployment.
It helps catch bugs, improve design, and share knowledge; it can also support security and compliance.
Keep PRs small, provide context, and treat review as a collaborative practice so it helps rather than blocks.