第五章 要多少只眼来驯服复杂

从宏观上，可以说市集风格大大加速了调试和代码演进，但是如果想从微观（开发者和测试者日复一日的工作中）上，准确理解这是如何和怎样起到作用的，却又是另一回事了。在本章中（作于本书初版后三年，采纳了阅读本书，并身体力行的开发人员的意见），我们将关注其背后的机理，对于技术不感兴趣的读者可以安心的跳到下一章。

理解问题的一个关键在于认清如下的重要事实，那就是那些对源代码知之甚少的用户所提交的错误报告通常派不上大用场。因为他们一般只看到表面症状。在提交错误报告的时候，习惯从自身环境出发，这样（一）会忽视重要的背景数据，（二）通常会遗漏重现错误的关键步骤。

更深层的问题是，开发者和测试者的思维模式不同。测试者是由表及里的看问题，而开发者则是自内而外。在封闭源代码的开发环境里，他们被各自的角色羁绊，往往各说各话而且认为对方很难沟通。

开源开发打破了这种束缚。基于源代码，测试者和开发者可以很容易建立一个统一的模型，并借此有效沟通。仅仅描述表面症状的问题报告和深入源代码基础抽象模型的报告，对于开发者而言作用是截然不同的。

在代码层，即使一个不完整的提示性错误描述，都可以让它们在大多数情况下得以修正。比如当某个公测人员指出：“在某某行存在边界问题”，甚至只是说出“在某某条件下，变量溢出”的时候。通常进行一次对于问题代码的快速扫描就足以锁定成因，加以修复了。

所以，如果公测人员和核心开发者都对代码心中有数，那么沟通和协作就很容易展开。这就意味着节省核心开发者的时间，即使协作者众多。

另一个节约开发者时间的方法源自典型的开源通讯结构。我在文中使用了“核心开发者”一词，这有别于“项目核心”和“项目外延”。（“项目核心”一般很小；通常包括一到三个核心开发者，当然如果只有一人也不足为怪；“项目外延”则通常包括数以百计的“公测人员”和“贡献者”）

正如布鲁克斯定律所言传统软件开发结构下的根本问题是：“为已经延期的项目增添人手会让它拖的更久。”通俗的讲，布鲁克斯定律昭示了：项目的复杂度和通讯成本会以开发人数为基础，呈现平方指数的增长态势，而绩效则仅能直线上升。

经验证实，错误大多集中在（不同人编写的）代码的接口处，而沟通/协调成本则会随着人员交流渠道的增加而增加，这就是布鲁克斯定律建立的基础。然而问题也会随着开发者沟通渠道的增多而增加，后者恰好等于开发人数的平方。（更确切地说，是遵循N*(N-1)/2公式，其中N代表开发者人数）

布鲁克斯定律（对于开发团队过大所导致的令人担忧的结果）的分析是基于一个潜在假设的：即项目必须采用全向连通的通讯结构，也就是说每个人都能与其他任何人取得联系。然而在开源项目中，外延开发是可以分离的平行子环节，彼此关联甚少。代码变动和错误报告都流经项目的核心团队，只有在那里我们才需要担负“布鲁克斯式”的管理成本。

代码层的错误报告对开发大有助益的原因还有很多，然而它们都围绕着一个事实。那就是：同一个错误在不同的操作习惯和环境下会表现出不同的症状。这类问题通常复杂隐蔽，难以重现和静态捕捉，它们正是造成软件长期问题的祸根。（比如动态内存管理出错或者随机窗口中断的影响）

一则源自测试者的（源代码层）试探性描述（例如“我觉得1250行附近像是有个信号处理窗口”或者“你在哪把缓存清零了？”），就可能会成为“当局者迷”的开发者同时解决六七个不同表象问题的关键线索。我们往往很难为五花八门的症状找到对应的错误，但是只要你发布的够频繁就无需为此担忧。因为其他协作者会很快的去查看自己提交的问题是否已经被修正了。多数情况下，源代码层的错误报告可以让许多问题没有经过特定修补就消失殆尽。

对于复杂多变的错误，从表面症状探索其成因的途径通常也很多。而对开发者和测试者而言，走哪条路则取决于他们自身所在的环境，而且也可能因为时间而产生一些无法预期的变化。实际上，开发者和测试者在为症状寻找病因的时候，都可以看作是对程序某部分运行状态的“半随机”取样。错误越是隐蔽复杂，取样对症的成功率也就越低。

对于简单易于重现的错误，重音应该落在“半”而不是“随机”上；此时，调试技巧和对代码以及其结构的熟识能派上大用场。然而对于复杂的错误，重音则转向“随机”。因为在这种情况下，众人多管齐下比少数人循序渐进要强的多——即使这“少数人”的平均水品很高。

如果挖掘错误的途径不一，很难凭表面现象预测的话，并行纠错的效果就很明显了。一个循序渐进的开发者可能一开始就选择了一条复杂的途径，当然他也可能一开始就选择到了简单的途径。让我们换一个角度，如果软件发布的够及时，那么众人就可以多管齐下。他们其中很可能有人立即就能找到一条快捷的途径，所以在极短的时间里就能修复问题。项目的维护人员看到改进，于是发布新版本。这样，那些通过其他困难途径探索同一个错误成因的人就可以在浪费掉更多时间之前停下来。【注1】

注释：

1. 根据为我提供不同难易追踪途径的读者的推测，这种对多表象错误的追踪的复杂度呈“指数”分布（我理解为高斯或者泊松分布，而且这听上去很有道理）。要是能通过实证绘出类似分布曲线的话，绝对很有价值。假如其与等概率分布平行线大相径庭，那么即使独自开发也应该努力效仿市集模式。也就是限定追踪问题的成因的时间，如果在限定时间内没有结果，那么就跳转到下一问题。坚持有时不见得是件好事……