沟通的收益和成本

在我看来，代码审查所暴露出的问题本质上就是如何权衡沟通的成本和收益的问题。

在软件开发过程的发展中，无论是从一开始的瀑布，后来的敏捷，还是当下的精益。都有很大一部分篇幅是在强调沟通或者说是强调沟通方式的演进，都是为了解决已有沟通方式所带来的各种限制和问题。

例如在我们自己的项目中就采用以下的实践来促进团队内外的沟通，包括：迭代计划会（Iteration Planning Meeting），每日站会（Daily Standup），代码评审会（Code Review），回顾会议（Retrospective Meeting）；还有XP中的结对编程(Pair programming)，现场客户 ( On-site Customer )等。

而沟通的好处是可以得到快速的反馈，无论是80年之前就出现的PDCA环还是前两年大热的精益创业，都是在强调快速反馈和基于反馈的快速迭代，通过这种方式来消除生产和创业过程中造成的各种浪费。

但是（对，又是但是……），沟通也是有成本的，而且成本一般都还不低，相信这点也不需要多解释，大家肯定都经历过各种各样效率极低令人抓狂的讨论或是会议。

在沟通的成本和收益同时摆在我们面前，如何做出选择？如何才能设计一套刚刚好的沟通体系，平衡收益与成本，来满足团队和项目的需要呢？

沟通金字塔

在读《重构》的时候，我深深地体会到：

这个世界上没有什么是不变的，包括变化本身。所以要想得到解脱，我们就需要从简单的对与错，好与坏的漩涡中跳脱出来，用变化的眼光来看待周围的事物，并做好一直变化的准备。

而面对沟通成本与收益的选择困境时，我第一个想到的就是测试金字塔。了解测试金字塔的同学肯定都知道，测试金字塔是一个很好的工具，它帮助我们从单一的测试选择困境中跳脱出来，将各种不同类型的测试建立起关联、纳入一个统一的体系，从而让我们可以在一个更高的维度来系统的思考和审视每一种测试的策略，关注点也从简单的“该不该”变为了“如何变化”。

图2. 测试金字塔

至于“如何变化”？我们可以通过在金字塔上添加一层新的测试种类来弥补整体测试策略中粒度太粗的问题；也可以根据项目情况通过移除一层测试种类，用其上层或是下层的测试来覆盖其测试用例，来减少成本；也可以通过将某个测试用例在金字塔中向上层或是向下层移动来寻找收益与成本的平衡。

举个实际点儿的例子，例如我可以将一些基于UI的集成测试用例下移，用成本更低的单元测试来覆盖从而减少成本，加快反馈速度；也可以将一个单元测试用例上移，用基于UI的测试来增加其稳定性的和体现的业务价值。

看，我们讨论的内容从简单的要不要写UI测试，需要写多少单元测试测试已经被转换到对于整体策略的变化和调整上来了。那对于代码审查的问题能否也通过金字塔这个工具转换到更大的空间上寻求突破呢？这就是沟通金字塔。

图3. Iteration Planning Meeting

相比于测试金字塔中的“UI 、Service、UT”，“Iteration Planning Meeting、 Code Review、 Pair programming”就可以类比成沟通金字塔，和测试金字塔一样更靠近金字塔顶端的（例如迭代计划会）沟通频率越低，成本越高，但越接近业务；越靠近金字塔底端的（例如结对编程）沟通频率越高，成本越低，越接近实现。这几种不同的沟通方式所沟通的内容肯定也会有所重叠，通过将各个层次的沟通方式进行组合来保证我们团队的整体沟通质量，就像通过金字塔中的各种测试层次的组合来保证产品质量的一样。

图4. Pair programming

如果可以这么类比的话，那我们对于沟通质量的管理也应该是动态的、系统的、从整体上出发的。例如就可以通过在沟通金字塔中添加一层新的沟通机制来弥补沟通粒度过粗的问题，例如QA Team现在在做的每周例会就是一个好的例子；也可以将一些沟通内容通过层次（上下）的调整，甚至是通过直接减少一层沟通方式来优化我们的整体沟通效率，例如我们可以通过增加结对编程的Switch频度来替换掉成本更高的代码审查。而目标就是通过不断地动态调整和优化沟通结构，试图寻求一个沟通成本，沟通收益，沟通效率平衡的沟通环境。

本文转载自健荐公众号。

原文链接：https://mp.weixin.qq.com/s/9l-549sddZ_JFMqdNC8CgQ

创作场景

不做代码审查又怎样（二）