Mob Code Review (Mob CR): A Practical Guide to Collaborative Code Review

Mob CR (Mob Code Review) is a collaborative code‑review method inspired by Mob Programming, where a team gathers to review a selected code snippet together.

What is Mob CR

Mob CR stands for “Mob Code Review”, meaning a group‑based code inspection.

Goals of Mob CR

Quickly establish or rebuild team standards for code quality.

Educate new members.

Assess team members’ understanding of code quality.

Which Teams Should Use Mob CR

Any team lacking a unified view of code quality or engineering discipline should adopt Mob CR, especially teams with many new members, newly formed teams, teams that have not performed code reviews for a long time, or teams that frequently discover issues during reviews.

Organization and Process

Mob CR consists of five steps:

1. Select a code fragment

Choose a piece of code (typically 400–600 lines, up to 1500 lines if familiar) to review.

2. Individual review

Each participant independently reviews the code and marks issues.

3. Choose a facilitator

Appoint an experienced “driver” to lead the Mob CR session.

4. Formal Mob CR session

Under the driver’s guidance, the team discusses each comment, resolves disagreements, and reaches conclusions.

5. Code cleanup

Assign one person to apply the agreed‑upon changes and merge them into the production repository.

What to Review

Code review can be divided into four progressive layers:

Automated scanning tools (mechanical checks).

Basic code standards (manual checks).

Design and implementation quality (manual checks).

Potential better implementations (manual checks).

The primary aim is not merely to find bugs but to improve overall code quality, readability, and maintainability.

Example Session

A recent Mob CR covered 6 files, 1529 lines of code, with 130 prior review comments. The formal Mob CR lasted 4 hours and revealed several style issues and design improvements, such as replacing unstructured YAML configuration with protobuf for better schema enforcement and adopting resource‑oriented API design.

发现的主要设计问题如下：

老司机指出，对于其中一个配置文件，如果用 protobuf 把配置定义清楚，直接交给不同的语言去 unserialize， 要比使用没有 schema 的 yaml 格式文件要好得多得多。

而且，这样一来，各个语言也都能保证一致性。

References to Google’s API design guide and additional resources are provided for deeper learning.

Further Reading

Recommended articles: “How to Achieve Efficient Code Review” and “Case Study: How Google and Facebook Conduct Code Review”.