How Effective Code Reviews Can Transform Your Team’s Quality

Reference Materials

"How Big Tech Companies Play Code Review" – Liang Songhua, JD Senior Engineer

"Learning How Facebook Leverages Code Review for Efficiency" – Ge Jun, Former Facebook Tech Lead

"Which Code Review Method Fits My Team" – Ge Jun, Former Facebook Tech Lead

"Talking About Code Review" – Xiong Yi, Oracle Chief Software Engineer

"6 Common Problems in Code Review" – Songhua Pidan, InfoQ

"Code Review: Hopes and Sorrows" – Hu Feng, JD Chengdu Research Institute Technical Expert

Code, like entropy, tends to decay without external force; as code accumulates it can rot and break. While we know the problems, changing the status quo is hard. When planning the next iteration, ensuring new code quality becomes crucial, especially during rewrites. This article offers a practical guide to help teams improve code review.

Why Review?

Consequences of Not Reviewing

Code quality reflects product quality; unstable products with bugs hurt customer satisfaction and reputation.

Poor code increases future maintenance costs, especially when changes are delayed and team members turnover.

Unstandardized, unreadable code leads to resistance during hand‑offs, resulting in chaotic patches and further degradation over years.

Technical debt can cause anything from localized anomalies to complete rewrites.

From physics, entropy shows that without external force, systems become more chaotic, making standards and reviews invaluable.

Software design must handle long‑term change; decaying code cannot support it.

In product development, lack of review cannot sustain.

Benefits of Review

Code review is a low‑investment, high‑output activity, offering personal habit, method, and knowledge gains.

It provides six major benefits:

1. Early detection of bugs and design issues. Early discovery reduces fixing costs.

2. Improves individual engineering skills. Peer suggestions raise code quality.

3. Facilitates team knowledge sharing. Reviewed code becomes team code, helping others understand design and implementation.

4. Targets specific quality aspects. Experts can focus on security, performance, UI, or high‑risk code.

5. Unifies coding style. Often automated with tools.

6. Social function. Knowing code will be reviewed changes developer mindset.

Review Challenges and Controversies

Most disputes focus on reasons or excuses for skipping reviews.

1) Time‑consuming effort

Tight deadlines and overtime make developers reluctant to review.

2) Impact on team building

Disagreements during review can cause friction.

3) Subjective preferences

Reviewers may impose personal style preferences.

4) Unbalanced team composition

Too many inexperienced members and few seniors can reduce review effectiveness.

5) Resistance to review

Some confident developers feel reviews are nit‑picking.

6) Formalism and poor effectiveness

Poorly executed reviews become a mere formality.

Understanding Review Formats

Manual inspection is called review; automated checks are called code analysis. Common formats:

Machine checks

Manual reviews

Pure online review

Offline screen‑sharing review (recommended)

Offline screen‑sharing is recommended despite being traditional, as its benefits outweigh costs.

Review Objects

Define which changes require review; major changes need multiple reviewers, minor changes need a peer check.

Review Participants

All personnel closely related to the business should attend, such as:

Developer’s mentor

Colleague responsible for the next workflow step

Involving them ensures information symmetry and prevents missed changes.

What to Focus On During Review

Common mistakes: reviewers impose personal opinions.

Encourage documenting coding standards to avoid bias.

Primary goals:

Maximize team benefit

Key focus points:

Obvious logical errors

Adherence to coding standards

Readability and maintainability

Violation of basic design patterns

Should not over‑focus on:

Whether code runs

Business requirement fulfillment

Coverage of business scenarios

These aspects are the responsibility of developers and testers.

Review Process Steps

Efficient programmers avoid frequent interruptions; follow a structured plan:

Agree on a specification document to avoid subjective preferences.

Schedule reviews (e.g., every Monday), estimate effort, align with testing and release timelines.

Provide supplementary material: background, code changes, impact scope.

Conduct the review; decide on re‑review based on severity.

Ensure essential elements (monitoring, comments) are present; reject otherwise.

Regularly refine code standards based on review outcomes.

Key Review Operations

Increase commit atomicity – submit small, logical units.

Submitting half‑finished features or a week’s worth of code makes reviews painful.

Improve commit message quality – include title, description, and test details.

Bad examples: "BUG", "FIX", "Update". Good practice: three‑part messages with clear purpose and test info.

Enforce detailed test descriptions and atomic commits.

Commit messages should be concise (<70 characters) and descriptive.

Key Review Principles

Mutual respect – reviewers spend time reading unfamiliar code; provide clear context and avoid nit‑picking.

Discussion‑oriented – reviews aim to discuss, not judge, fostering open technical exchange.

Common Review Issues

Typical problems to document in coding standards:

Lack of comments and change description

public Article GetArticleById(long id) { return null; }</code><code>public MaterialPO GetMaterialById(long id) { return null; }</code><code>public ArticleVO GetArticleByIdWithoutStatus(long id) { return null; }

Improper third‑party reliance

// Bad example
Boolean SaveError(List<ShareDetail> list) {
    if (list.isEmpty()) { return false; }
    int id = list.get(0).getId();
    return Save(id, list);
}

// Good example
Boolean SaveRight(Integer id, List<ShareDetail> list) {
    if (id == null || CollectionUtil.hasNull(list)) { return false; }
    return Save(id, list);
}

Excessive variable scope

public static void main(String[] args) {
    ShareDetail shareDetail1 = new ShareDetail();
    varErrorStep1(shareDetail1);
    ShareDetail shareDetail2 = varRight();
}

public static void varErrorStep1(ShareDetail shareDetail) {
    shareDetail.setId(111);
    varErrorStep2(shareDetail);
}

public static void varErrorStep2(ShareDetail shareDetail) {
    shareDetail.setName("hello");
}

public static ShareDetail varRight() {
    ShareDetail shareDetail = new ShareDetail();
    shareDetail.setId(111);
    shareDetail.setName("hello");
    return shareDetail;
}

Lack of staged results

// Bad example
public void SetpError() {
    Boolean flag = false;
    List<Integer> list = new ArrayList<>();
    for (Integer detail : list) {
        if (detail > 0) { flag = true; }
    }
    if (flag) { return; }
}

// Good example
public void SetpRight() {
    List<Integer> list = new ArrayList<>();
    for (Integer detail : list) {
        if (detail > 0) { return; }
    }
    // further steps
}

Logging issues

// Bad example
public Boolean logError(Integer id, List<ShareDetail> list) {
    if (id == null || CollectionUtil.hasNull(list)) { return false; }
    logger.info("logError run");
    try {
        return shareDao.save(id, list);
    } catch (Exception e) {
        logger.error("save error");
        logger.error("save error e:{0}", e.getMessage());
    }
    return false;
}

// Good example
public Boolean logError(Integer id, List<ShareDetail> list) {
    if (id == null || CollectionUtil.hasNull(list)) { return false; }
    logger.info("logError run");
    try {
        return shareDao.save(id, list);
    } catch (Exception e) {
        logger.error("save error");
        logger.error("save error id:{}, e:{}, list:{}", id, e, list == null ? list : JSONObject.toJSON(list), e);
    }
    return false;
}

Conclusion

To get the team to embrace code review as an essential daily step, improve review quality by clarifying formats, objects, participants, focus points, processes, and common issues. Encourage a team‑first mindset, involve testers when possible, and ensure continuous positive feedback.