Code Review Principles, Timing, Scope, and Conflict Resolution Guidelines

The purpose of code review is to ensure the overall health of a company's codebase, keeping it at a high standard as it evolves; all tools and processes used in reviews should be designed to achieve this goal.

01 Review Principles and Timing

1.1 Review Principles

Encourage questioning.

Maintain code style and follow development standards.

Prioritize design principles while respecting personal preferences.

Value every line of code.

Prefer face‑to‑face review whenever possible.

1.2 Review Timing

Start the review as early as possible, no later than the early testing phase. For asynchronous reviews, the process should not exceed one working day; if it does, provide preliminary feedback at the start of the review.

02 Review Scope

The review should assess the following aspects:

Functionality : Does the change list meet its intended goals? Are edge cases such as concurrency, data permissions, performance, and race conditions properly handled?

Complexity : Is the added complexity justified? Is the design readable and the abstraction elegant?

Unit Tests : Are there unit tests? Are they readable, contain assertions, and cover as many logical branches as possible?

Naming : Do names follow conventions and clearly express the purpose of the item?

Comments : Are comments necessary and do they fully explain the code’s intent rather than merely describing what it does?

Code Style : Suggestions for style improvements should be marked as optional nitpicks. Nit:

Documentation : Is relevant documentation created or updated, and does it follow the project’s format?

Context : Does the change affect upstream or downstream business logic? Could it degrade overall code quality or architecture?

Excellent Design : Highlight and acknowledge any particularly good design decisions.

03 Review Scale

The depth of review should be proportional to the impact of the change; high‑impact changes warrant a more thorough examination.

04 Resolving Review Opinion Conflicts

When disagreements arise:

Who is right? Reviewers should first consider whether the developer, who is closest to the code, might be correct.

Address later? Developers may request to postpone fixes due to tight schedules, but such postponements often lead to forgotten issues; it is best to resolve feedback promptly.

Strictness If reviewers are perceived as overly strict, polite persistence is necessary because rigorous reviews lead to higher‑quality code and long‑term benefits.

05 Conclusion

Code review provides lasting value for both reviewers and authors. Raising issues, even minor ones, fosters continuous improvement and higher overall work quality.

Recommended reading:

京东云RASP云原生安全免疫创新实践

交易履约之产品中心实践

从原理到应用，人人都懂的ChatGPT指南

VOP消息仓库演进之路|如何设计一个亿级企业消息平台