The Importance, Challenges, and Best Practices of Code Review in TDSQL‑C

Background and Motivation – A typical newcomer may write 800 lines of code, submit a merge request, receive style comments, fix them, and merge to master, only to worry for months about potential crashes. This illustrates why systematic code review is essential.

Why Code Review Matters – It provides healthy social pressure, improves code quality and maintainability, uncovers hidden defects (performance, compatibility, error handling), facilitates knowledge sharing, double‑checks requirements, and ensures code is understandable and maintainable.

The accompanying diagram from *Applied Software Measurement* shows that most defects are introduced during coding, discovered in testing, and become exponentially more expensive to fix later, highlighting the critical role of code review before release.

General Code Review Challenges – Reviewers must understand project context, design, and related modules; time pressure can reduce efficiency; large merge requests (thousands of lines) are overwhelming.

What Is TDSQL‑C? – TDSQL‑C is a cloud‑native, distributed database built on MySQL, offering high performance, low cost, massive storage, low replication latency, rapid scaling, fast rollback, and serverless capabilities.

In TDSQL‑C, the traditional MySQL architecture (local logical/physical logs) is replaced by a compute‑storage separation where the storage layer replays physical logs, leading to massive code changes and a large, multi‑team project, raising the bar for review.

TDSQL‑C Code Review Process

Create a personal branch from master.

Develop on the branch, documenting design decisions via email.

Run unit, performance, long‑run, and valgrind tests.

Submit an MR; CI runs unit tests, static analysis, and coverage reports.

Ensure both total and incremental coverage exceed 90%.

Notify reviewers, providing issue ID, design docs, and test data.

After review approval, merge into master and proceed to release.

Author Requirements

Submit small, incremental changes.

Document modified files and new features for reviewers.

Reviewer Requirements

Build and run the code to verify behavior.

Provide timely feedback.

Consider how they would implement the changes before commenting.

Review Checklist

Adherence to coding standards.

Alignment with requirements and design documents.

Algorithmic efficiency and optimal implementations.

Attention to details such as memory management and error handling.

Reasonable comments.

Comprehensive unit tests.

Commit Log Guidelines – Each commit must include: type (bug fix or feature), related issue, concise subject, problem description, solution, MR number, and reviewer name.

Optimizations to the Review Process

Classify review comments with tags: [blocker] (must fix), [optional] (optional), [question] (needs clarification).

Hold weekly online stability analysis meetings to share real‑world issues and preventive measures.

Promote code review as a cultural practice rather than a rigid rule, encouraging ownership, senior engineer mentorship, dedicated review time, module owners, and shared responsibility for merged code.

Future work includes leveraging machine‑learning‑based defect detection to further enhance review effectiveness.

For more details, click the “Read Original” link at the bottom of the article.