如何提升技术团队的工程有效性，一种的高效方式就是…它…
持续交付20约 4 分钟“我知道，并没有多少软件团队做 Code Review，即使做了 Code Review，也是形式主义居多。但是，我仍旧希望给那些真正愿意在提升团队工程技能水平的上花费时间与精力的团队技术管理者，一个很好且行之有效的做 Code Review 的工具，那就是 Mob CR，即：扎堆代码检视。”
1
Mob CR 是 Mob Code Review 的缩写。
Mob 是扎堆的意思。
所以，Mob CR 就是「扎堆代码检视」。
它的名字源于：Mob Programming，Mob Programming 介绍参见：
【B站视频简介（短）】
https://www.bilibili.com/video/BV1a3411n7i7/
【B站视频简介（长）】
https://www.bilibili.com/video/BV1TZ4y1m724/
【介绍PPT（长）】
https://docs.qq.com/pdf/DYk9xZkpwak94SGxH
2
Mob CR 的目标
通过集体实战，快速让团队技术负责人
快速建立（或重建）团队对代码质量的标准与要求。
教育新成员。
近距离了解团队成员对代码质量的认知水平。
3
这些团队的特征包括：
新成员比较多的团队
新组建的团队
团队长时间没有做过代码Review
Code Review 中发现较多问题的团队
4
Mob CR 的
1. 团队找出一段需要被检查的代码片段。
一般来说，400 ～ 600 行的代码量。如果对代码比较熟悉，最多可以到 1500 行。
2. 独立代码检视。
参与 Mob CR 的所有人事先自行对这段代码进行单独代码检视，标记找到的问题。
这一步与正常的 CR 一样。
3. 约定一个时间段，并事先推选一名老司机，主导这次 Mob CR。
4. 正式 Mob CR
在老司机的带领下，对多人的检视结果进行做个检视，逐条梳理每一条评论。
直到所有人的评论都被检视并讨论过。
对有分歧之处，进行讨论，并得出最终结论。
得出最终结论是重中之重。
5. 代码清扫
这是本次 Mob CR 的最后一步，即：
指定一人将整个代码片段按结论对这段代码进行清扫，并合入生产代码库。
5
至少可以分四个递进层次。分别是：
自动化扫描工具（机械式）
代码基本规范（人工方式）
现有的实现与设计（人工方式）
我是否有个更好的实现方法（人工方式）
第一层：自动化扫描工具拦截
就是当代码的作者提交给代码检视者进行检视之前，由事先定义好的自动化扫描工具阻挡一波。
成功通过自动化扫描工具的检查之后，就可以真正投入人力了。
第二层：code-standard-smell 或明显的代码缺陷
在此步骤中，
若本次的代码变更中有太多基本的规范性问题，可能直接打回让作者修改，而不必
例如：提交注释是否清晰达意，是否与所提交的代码内容相吻合，
第三层：代码设计与实现
从代码维护者的角度阅读代码，发现代码可能存在的问题或安全风险，或者更好的优化点，并指出来。
能发现代码中的 Bug 当然好，
但是，
并不应以每次都找到现有代码中的 Bug 为代码检视的主要目标。
尤其是在做日常 CR（即每次提交代码都做CR时），
「能够发现可能的 Bug 或安全风险等」属于 Nice to have。
更多应该强调的是：
这次代码变更是否让代码库的整体质量变得比原来更好，更易读懂？
以后再来修改这段代码时，是否会因为代码太差而改不动？
最不济，也至少要不能比没有修改之前变得更差！
第四层：是否有更好的实现方法
代码检视者针对这段变更，是否能想到比目前的实现方案更好的方法。可以提出来，与这段代码变更的作者进行讨论。
6
下面是一次 Mob CR 的简单记录。
这次 CR 的代码规模
6个代码文件，1529行代码，在CR之前一共有130个有效 Review Comments。
这次 CR 的耗时
第四步「正式 Mob CR」的过程一共历时 4 个小时。
发现的规范性问题包括（内容并不全面，仅为示例）：
以下与代码上下文有关，仅为了示例。
发现的主要设计问题如下：
老司机指出，对于其中一个配置文件，如果用 protobuf 把配置定义清楚，直接交给不同的语言去 unserialize， 要比使用没有 schema 的 yaml 格式文件要好得多得多。
而且，这样一来，各个语言也都能保证一致性。
同时，老司机还给出 API 的设计原则，应该是「面向资源的 API 设计」。
同时给出了谷歌用的 API 设计指南，链接在这里。
https://cloud.google.com/apis/design/resources
本设计指南的目标是帮助开发者设计简单、一致且易用的 API。
— THE END —