How a Frontend Team Built a Scalable Code Review Process

Background

Technology Stack

The beauty‑industry frontend team primarily uses a multi‑platform stack covering web, mini‑programs, native apps, and other endpoints.

Team Structure

Initially, developers were assigned by endpoint, leading each person to maintain four different codebases, which created diversity but also bottlenecks due to the need to master all four contexts.

A small frontend technical committee was formed to address these challenges.

Summarize existing technical standards, provide unified training and documentation.

Create a standardized development workflow.

Continuously adopt new practices and iterate.

Code Quality Issues

The team faced several problems:

Frequent bugs and repeated mistakes across developers.

Hard‑to‑maintain code after iterations, with poor readability and low reuse.

Poor module design limiting scalability.

Code reviews were conducted semi‑annually, but the process consumed significant time, similar to a garbage‑collection pause.

The team sought a faster, more frequent, and early‑stage code review approach to reduce rework and improve efficiency.

Requirement Definition

The core objectives of the new code review process are:

1. Control code quality and efficiency from the source

Standardize evaluation criteria.

Identify boundary issues.

Provide improvement suggestions.

2. Share and iterate collective coding wisdom

Exchange ideas and practices.

Document best practices.

Iterate standards.

Potential challenges include ensuring sufficient information for reviewers and aligning reviewer expertise with the code’s tech stack.

V1.0 Standardization

Establish Standards

1.1 Presentation

Introduce unified coding standards, best practices, and principles across all endpoints.

1.2 Review Group

Form a dedicated review group composed of experienced developers from each endpoint.

1.3 Evaluation Dimensions

Score each dimension from 1 to 5, with a baseline of 3. The overall score is the average.

Basic: adherence to team standards and change volume; difficulty may add points.

Architecture: presence of overall design, alignment with design docs, and better solutions.

Code: simplicity, readability, avoidance of duplication, proper use of enums, components, and refactoring.

Robustness: handling of boundaries, bugs, and basic security (e.g., XSS).

Efficiency: contribution to shared libraries and component repositories.

1.4 Submission Format

Review requests are posted in the enterprise WeChat group with a standardized format including MR address, product docs, UI mockups, technical design, efficiency platform, and API docs.

mr address, product documentation, UI draft, technical design, efficiency platform, API documentation

Additional context may be provided verbally if documentation is insufficient.

1.5 Review Requirements

Conduct review before testing.

Reviewer scores each dimension and calculates the total.

Comments can be added in GitLab.

Address feedback before release.

Include review scores in the test email.

Merge MR from feature to release branch.

Periodically share review records.

1.6 Review Focus

Check the scope of code changes, focusing on core impact.

Provide detailed explanations for any checklist violations.

Discuss design highlights, shortcomings, bugs, and best practices.

Share findings in weekly meetings.

Single Review Flow

Outcome Examples

Developers adopt a habit of documenting design and impact.

Both sides gain coding insights, raising overall code quality.

Design and details receive better protection.

Best practices and suggestions form a feedback loop.

V2.0 Platformization

While V1.0 achieved satisfactory standardization, it still suffered from:

Lack of automation in many steps.

Manual scoring and data collection.

No visual overview of review status.

The team decided to embed the entire code review workflow into an internal frontend tool platform to achieve visualization, automation, and digitization.

The effort is justified by quality control, capability quantification, and team‑building value, even without direct business revenue.

Requirement Analysis

Additional features collected from feedback:

Allow code authors to specify reviewers.

Support multi‑endpoint project configuration.

Display review score rankings on the homepage.

Export unified best‑practice documentation.

Integrate with related project platforms.

Technical Design

Database tables were designed and development tasks were allocated.

Product Mockups

Platformization automates repetitive tasks, letting developers focus on code and thinking.

The team gains a global view of code health, enabling data‑driven decisions for quality improvement.

Sustainable Governance

To keep the process alive, the team introduced:

Bi‑annual awards based on review scores to motivate excellence.

Dedicated owners to maintain the platform and collect feedback.

Inclusion of code review performance in developer assessments.

Source: https://segmentfault.com/a/1190000025141916