How to Do Code Review

Google's Engineering Practices Code Review Guide is one of the clearest and most practical documents on how great engineering teams review code. After reading it carefully, I found several principles aligned with my experience, especially the idea that code review is not testing functionality but evaluating the long-term quality of the system.

1. Code Review Purpose: Protect the Codebase, Not Hunt Bugs

Google emphasizes that the primary goal of code review is to maintain the long-term health of the codebase, not to nitpick or demand perfection. This means:

• Preventing new technical debt.
• Keeping consistency in design and architecture.
• Improving readability and maintainability.
• Ensuring future developers will understand the code.
• Sharing knowledge within the team.

My reflection: Code review is not for verifying functional correctness. That is the job of tests.

A reviewer should not act like QA. Reviewers look at the code from a high-level engineering perspective:

• Is this good code or bad code?
• Can another engineer easily understand and maintain it?
• Does it follow architectural patterns?
• Does it make the system simpler or more complicated?

I see many reviewers get stuck in small variable names or formatting, while the bigger question, "Is this code necessary, clear, and maintainable?" is forgotten.

2. Review the Design First, Code Second

Google recommends that reviewers begin with a design-level review. Before reading line-by-line code, answer:

• Does this design fit into the system?
• Is this the right place to put this logic?
• Should this be split into smaller components?
• Does this change introduce unnecessary complexity?

My reflection: Many teams jump into reviewing low-level details too early.

For example, someone submits a PR with poor architecture but clean formatting. Some reviewers say "rename this variable," but nobody asks "Should this code even exist here?"

A clean, readable, incorrect design is still bad code.

3. Maintainability Over Cleverness

The guide emphasizes readability, simplicity, and clarity over clever tricks:

• Clear naming.
• Small functions.
• Avoid large classes.
• Comments explain "why," not "what."
• Reduce cognitive load.

My reflection: Maintainability is more important than clever code. Good code review questions include:

• Can a junior engineer understand this?
• If someone reads this in 6 months, will they know what is going on?
• Is this the simplest way to implement this logic?

Complexity is expensive. Simplicity scales.

4. Tests Are Required, But Testing Is Not the Reviewer's Job

Google is very clear:

• Reviewers check whether tests exist and cover important cases.
• Reviewers do not manually test the functionality.
• The author is responsible for correctness.

My reflection: Code review is about code quality, not functional validation.

A reviewer ensures:

• Edge cases are considered.
• Tests match the behavior.
• Critical logic is covered.

But reviewers should not manually click buttons, run local scenarios, or validate business flows. That is the responsibility of the developer and the QA pipeline.

5. Small, Incremental PRs Are Best

Google insists:

• PRs should be small.
• Easy to understand.
• One logical change at a time.
• Large PRs reduce review quality.

My reflection: Large PRs guarantee lower-quality code review. When PRs are huge:

• People skim.
• Design problems go unnoticed.
• Bugs hide easily.
• Review fatigue happens.

A small, focused PR leads to better discussion, better design visibility, faster review turnaround, and higher maintainability.

6. Speed and Developer Respect

Google states:

• Reviewers should respond within one business day.
• PRs must not block progress unnecessarily.
• Feedback must be kind, respectful, and constructive.

My reflection: Code review is collaboration, not a power move. I try to:

• Ask questions, not make accusations.
• Suggest improvements.
• Explain reasoning.
• Balance speed with quality.
• Avoid personal style wars.
• Approve when the PR is good enough.

The goal is continuous improvement, not perfection.

7. Final Thoughts: What Code Review Really Means

Code review is the process of evaluating whether this code makes the entire system healthier and easier to maintain, not whether it works. This includes:

• Readability.
• Testability.
• Simplicity.
• Architecture alignment.
• Future-proofing.
• Reducing complexity.
• Avoiding technical debt.

When code review is done right, teams move faster, bugs decrease, knowledge increases, the system becomes simpler, and developers grow as engineers.

Reference: https://google.github.io/eng-practices/