Mastering Code Review: Objectives, Process, Checklist, and Best Practices

Code Review Goals

Identify problems early in the project, disseminate knowledge and help junior developers learn from senior engineers, promote mutual assistance and backup within the team, and improve code readability and maintainability by spotting "danger zones".

Code Review Process

All code changes must undergo review. The code must compile, pass static analysis tools (e.g., FindBugs), and succeed in unit tests before review. Review is required for projects or small tasks in the AONE system.

Review formats include:

Pair review – mandatory for all projects and tasks.

Group review – performed as needed, either randomly or for critical code.

Suggested incremental review – conducted continuously during development.

Scope: both product code and unit tests are reviewed; critical code must receive group review.

Reviewers must be familiar with the code and project and have participated in design reviews. For high‑risk changes, module owners or architects should be involved, and QA participation is recommended.

Code Review Content

Code style (using Hudson check tools).

Error and exception handling, including interface return value checks.

Business logic and loops.

Thread safety.

Resource handling – closing handles, preventing memory leaks (using Hudson tools).

Framework usage and performance issues.

Unit test cases – ensuring their effectiveness.

Code Review Methods

The developer introduces the code, explaining design ideas, data structures, and overall architecture.

Both parties discuss and exchange ideas.

The reviewer conducts a detailed review, recording findings and suggestions with a unified tool (e.g., Tala).

The reviewer and developer jointly discuss the review results, refactor, and improve the code.

Reusable review insights are documented as coding standards or added to a "danger zone" repository for team reference.

Suggested mode: incremental review to avoid long‑tail effects.

Note: Reviewers and developers are partners, not adversaries; the process aims to foster learning, knowledge sharing, and better product quality.

Appendix: Code Review Checklist

Code style and comments, including company copyright statements and consistent signatures.

Adherence to formatting standards; avoid wildcard imports and redundant imports.

Proper naming conventions for classes, interfaces, variables, and parameters.

Public variables should have descriptive comments; public methods and classes need clear documentation.

Complex algorithms should include appropriate explanations.

Ensure no usage of deprecated code.

Validate appropriate use of public/private/static/final modifiers.

Static constants must be accessed via class/interface names, not instances.

All Serializable classes must define serialVersionUID.

All if, for, while blocks should use braces.

Avoid overly complex statements; keep code simple and clear.

Never hard‑code URLs, file paths, or strings; use configuration or URIBroker.

Externalize non‑descriptive strings and numeric constants.

Avoid System.out/err and Throwable.printStackTrace() in production code.

Close streams, files, and connections promptly to prevent leaks.

Log at appropriate levels and check isXXEnabled before low‑level logging.

Minimize DAO calls in the business layer, especially inside loops.

Limit debug logging in production environments.

Ensure thread‑safe usage of shared objects.

Prefer StringBuilder for large string concatenations.

Avoid deep recursion; control recursion depth if used.

Prevent memory leaks from ThreadLocal objects; initialize them statically.

Handle exceptions properly and release resources afterward.

Disallow hard‑coded character set conversions (e.g., GBK↔8859_1).

Compile regular expressions wisely; avoid large, performance‑heavy patterns.

Limit use of String.indexOf() on large scales.

Method parameters should not exceed five; consider encapsulating related data in a bean.

Method bodies should stay under 50 lines; extract logic into smaller methods.

Avoid nesting more than four levels of if‑else; use design patterns like Strategy or Command.