太长不读
开发组要想从Code Review中持续获益，保持收益稳态，并不是一件简单的事情，因为Code Review是一个复杂系统。
和Code Review收益稳态相关联的因素有很多，包括业务、代码、人员、工具和过程。它们组成了一个非线形和过程不可预知的复杂系统。天真地期望持续投入时间，就能从中获益，最终往往事与愿违。
“必要多样性”法则告诉我们，能对付复杂的，唯有复杂。
而要想验证Code Review收益稳态的假设，只有进行花样繁多的持续考验。能证明假设的，唯有考验。
通过持续考验Code Review的收益稳态，能有效验证收益稳态的假设是否成立，并能促使开发人员通过实战，持续提升代码质量和编程能力。
引子
在辅导企业实践Code Review时，经常遇到下面这样的痛点：
- “Code Review发现不了什么关键问题”
- “以前Code Review发现的问题，之后又会反复出现”
- “如何确保开发组，真的从Code Review中持续获益？而不是一阵风？”
为了度量Code Review的成效，企业会度量一些指标，如代码提交经过Code Review的比例，Code Review中所发现问题的修复率，以及Code Review的频率等等。但这些指标都只能反映过程，而无法从中了解开发组是否真的能持续从Code Review中获益。
从这些痛点能够看出，开发组要想从Code Review中持续获益，保持收益稳态，并不是一件简单的事情，因为Code Review是一个复杂系统。
Code Review是一个复杂系统
一个复杂系统，最明显的特点，就是内外相互关联的因素错综复杂。而影响Code Review收益稳态的因素包括但不限于以下方面：
-
业务
代码作者与Review者对代码相关的业务知识的熟悉程度
业务人员能否把需求拆小再交给开发人员
-
代码
代码作者与Review者的开发技能
代码作者与Review者对相关模块已有代码的熟悉程度
代码作者与Review者的重构和整洁代码水平
代码作者与Review者的整洁架构水平
-
人员
代码作者与Review者的对Code Review的主动性
代码作者与Review者的表达能力，因为他们分别要有效地讲解代码和提出反馈
开发人员能否做到频繁小批的非破坏性提交
-
工具
阅读代码的工具的体验
为代码提反馈的工具的体验
度量Code Review的工具的体验
-
过程
开发组的任务分配模式，比如有些开发组把某个模块的所有开发任务，都分配给一个人，形成“单人开发”的局面，导致其他人不熟悉相关业务和代码，无法在Code Review时提出有价值的反馈
开发组的KPI，如缺陷数量不能超过KPI，而有些开发组直到代码到了UAT测试上线前，才进行Code Review，其间发现的问题，由于KPI的限制，而不敢提出缺陷进行解决
开发组做集体和一对一Code Review的方式和频次，如Code Review频次少，导致每次Review的代码太多，难以找出关键问题
开发组对Code Review的总结沉淀
开发组的开发工作量，如工作量大，导致减少Code Review频次
上面提到的种种因素交织在一起，彼此制约，使得Code Review形成了一个非线形和过程不可预知的复杂系统。天真地期望持续投入时间，就能从中获益，往往最终事与愿违。
能对付复杂的，唯有复杂
该如何面对复杂系统？
“要实现控制，控制系统能够执行的行为的多样性，必须不低于需要应对的环境动荡的多样性。”
控制论学者艾什比所提出的上述“必要多样性法则”（Law of Requisite Variety），给了我们如下启示：能对付复杂的，唯有复杂。
所以，要想保持Code Review的收益稳态，要做到以下三点：
- 方法多样 高于 方法单一
- 成员主动 高于 成员被动
- 多动脑筋 高于 照抄照搬
而该如何验证Code Review的收益稳态？以下场景是不是很熟悉？
如何验证办公大厦应对火灾的实际水平？进行消防演习。
如何验证军队的实际作战能力？进行实弹演习。
如何验证数据中心应对故障的能力？进行故障演练。
如何验证下属没有瞒报？进行微服私访。
如何验证唐僧师徒四人西行取经的决心？四圣化作母女，试探他们的禅心。
如何验证一种新药的疗效？在志愿者身上做药物临床实验，试一试。
如何验证系统能够承受AWS云服务中的实例莫名消失的故障？在生产环境部署混沌猴工具，随机关闭一个实例，考验系统能否承受。
这些场景都有一个共性——考验。是骡子是马，拉出来溜溜。
再回到咱们的问题——而该如何验证Code Review的收益稳态？只有进行花样繁多的持续考验。
为什么要花样繁多？想想“必要多样性法则”。
如何考验开发组能持续保持Code Review的收益稳态？
答案是“变着花样持续考验”。
持续考验的价值在于，通过持续考验Code Review的收益稳态，能有效验证收益稳态的假设是否成立，并能促使开发人员通过实战，持续提升代码质量和编程能力。
持续考验Code Review收益稳态的步骤
-
定义收益：根据开发组的自身情况，定义当前Code Review所关注的各种收益。例如：
发现并修复代码中的业务逻辑错误
发现并修复发现代码中的非功能性缺陷
发现并修复发现难以理解的代码
让所有开发人员熟练掌握编程规范
-
定义收益稳态假设：从上述收益中，选择一个这次最想考验的，来定义Code Review相应的稳态假设。例如下面就是一个收益稳态假设：
- “当某个关键模块的新编写的代码中，出现了业务逻辑错误时，Code Review能够发现，并尽快修复和重新进行Code Review。”
-
确保开发组具备通过考验的能力：
- 例如选一个比较有挑战的例子，前面说到的一个痛点“Code Review发现不了什么关键问题”，如果主要原因是“单人开发”，那么就可以考虑将原来的“A角单人开发”，转变为“AB角双人开发”，来培养开发组对相关模块的Code Review的能力。只有培养出能力，才能进行下面的“考验”。否则是经不起考验的。
-
设计一次收益稳态的考验：设法让新代码出现一个“陷阱”，考验Code Review能否发现。
设计“陷阱”的方法多种多样，比如在上面的例子中，B角事先阅读A角编写的新代码，把所发现的缺陷作为“陷阱”，考验A角能否在Code Review中发现；或者A角故意在代码中留下设计好的缺陷，并将其作为“陷阱”，考验B角能否在Code Review时发现。
“陷阱”越隐蔽，越“阴险”，效果越好。所以设计“陷阱”时，不要太客气。
-
考验Code Review能否发现“陷阱”：在Code Review时，观察“陷阱”能否被其他不知情的参与者发现。若能发现，则表明Code Review通过了这次考验，可以换个收益稳态进行新的考验；若没能发现，则表明Code Review机制存在漏洞，需要设法改进，并就该收益稳态再次进行考验。
- 注意Code Review最后不要忘记告诉大家自己所设下的“陷阱”，否则就真的给自己“下套儿”了。
-
回顾考验：回顾并记录这次收益稳态的考验结果。
对于通过考验的“陷阱”，可以作为这次Code Review的收益，记录下来。未来等开发组有新人加入后，可考虑再次进行考验。
对于所发现的未通过考验的Code Review机制的漏洞，要规划改进措施，并安排进一步考验。比如在上面的例子中，若发现B角没有通过考验，那么可以将原来主要由A角编写代码，换为主要由B角编写代码，让B角充分锻炼，以便通过下次考验。
规划下一次考验：若上次考验未通过，则回到第3步，设计一个同类的“陷阱”，再次考验。若上次考验通过，则回到第1步，设计下一个收益稳态的考验。
总结
如果发现“Code Review发现不了什么关键问题”，“以前Code Review发现的问题，之后又会反复出现”，“想要确保开发组，真的从Code Review中持续获益，而不是一阵风”，就可以变着花样持续考验，用持续的实验，来证明这些问题已经得到了解决。因为能对付复杂的，唯有复杂。能证明假设的，唯有考验。
