Mob Code Review (Mob CR): A Collaborative Approach to Raising Team Code Quality

Many software teams either skip code review or treat it as a formality; Mob CR (Mob Code Review) offers a practical, collaborative alternative that brings the whole team together to raise engineering standards.

Mob CR stands for “Mob Code Review”, where “mob” means a group gathering; it originates from the Mob Programming concept.

The goal of Mob CR is to quickly establish or rebuild a shared set of code‑quality standards, educate new members, and gauge each participant’s perception of code quality.

Teams that should adopt Mob CR are those lacking a unified view of good code, such as groups with many new members, newly formed teams, teams that have not performed code reviews for a long time, or teams that frequently encounter review‑related issues.

The Mob CR process consists of five steps: (1) the team selects a code fragment (typically 400‑600 lines, up to 1500 lines for familiar code); (2) each participant independently reviews the fragment and marks problems; (3) a senior “driver” is appointed to lead the session; (4) the formal Mob CR meeting is held, during which all comments are discussed and consensus reached; (5) a designated person cleans up the code according to the conclusions and merges it.

Code review itself can be viewed in four progressive layers: automated scanning tools, basic coding standards, design and implementation review, and finally, proposing better implementation approaches.

While finding bugs is valuable, the primary focus should be on whether the change improves overall codebase quality, readability, and future maintainability, ensuring the code does not become worse.

An example Mob CR session examined six files (1,529 lines) with 130 prior review comments; the formal discussion lasted four hours. Review findings included style violations, a suggestion to replace un‑schemaed YAML with protobuf for configuration files, and API design recommendations following Google’s “resource‑oriented API” guidelines.

发现的主要设计问题如下： 老司机指出，对于其中一个配置文件，如果用 protobuf 把配置定义清楚，直接交给不同的语言去 unserialize， 要比使用没有 schema 的 yaml 格式文件要好得多得多。 而且，这样一来，各个语言也都能保证一致性。

The article concludes with a brief promotion for a limited‑time Golang continuous‑deployment course, which is unrelated to the technical content.