How Stage-Based Code Review Transforms Large Frontend Changes

DEF (Alibaba Frontend R&D Platform) built a CodeReview system on Aone and KAITIAN, aiming to provide a better code review experience for frontend and establish a quality evaluation system tailored to frontend characteristics. The “CR Quality Thinking” series consists of three parts:

CR Quality Thinking: Metrics and Current Situation

CR Quality Thinking: Solutions

CR Quality Thinking: Staged Review Practice

This article introduces the design and implementation of the staged review that has been launched, analyzes usage data to identify existing problems, and proposes an optimized version.

Background

Previous articles noted that large‑size CRs significantly affect review quality, yet about 20% of CRs in DEF’s system reach that scale due to business complexity. Splitting a single large change into multiple reviews became an urgent problem. Earlier solutions included commit‑based splitting, machine‑learning‑based intelligent splitting, and an engineering‑driven approach called 阶段化代码评审.

Existing Staged Review Process Design

Process Derivation

The conventional review process shows the entire change at once. The staged review splits a change into multiple phases, each reviewed separately without extra change information.

Developers submit a review after completing each phase; reviewers focus only on the current phase’s code.

Version Skip Algorithm

To ensure reviewers see only new content in each phase, the system compares Git push versions. When mergeBase changes, a compatibility algorithm removes the impact of that change.

Full derivation is available in the article “Pure Front‑end IDE CR: Version‑Based CR System Implementation”.

Process Interaction Design

The state flow of a review is illustrated below.

Reviewers see new changes based on the last approved version and can click version nodes to view diffs. Each small version behaves like a sub‑CR, preserving prior comments.

Process Notification Design

A notification mechanism monitors code size and triggers alerts via DingTalk or page reminders, guiding developers and reviewers through each stage.

Data and Limitations of the Existing Process

Since its launch on 2021‑06‑24, over 1,500 CRs used staged review (at least two phases) out of more than 20,000 total CRs. Click‑through data shows 3,000 view events, 1,500 submissions, and 800 expansions of staged details.

However, most staged CRs involve only minor line changes in later phases, indicating the process does not effectively split large changes into smaller, manageable units. A critical bottleneck is that version generation depends on reviewer approval, causing asynchronous delays and making the staged workflow hard to adopt.

New Staged Review Process

The key improvement removes reviewer dependence for version creation, making the developer the sole trigger for a new stage. The workflow now looks like:

Reviewers receive only the current stage’s changes, while the final review aggregates all stages, preserving prior comments for reference.

Conclusion

Stage‑based code review can effectively support large frontend changes by letting developers break down modifications into manageable phases, reducing reviewer overload and improving review efficiency. DEF continues to refine this capability to ensure large‑scale frontend changes are reviewed safely without compromising development velocity.