245    实际上，开发者和测试者在为症状寻找病因的时候，都可以看作是对程序某部分运行状态的´半随机”取样。

246    错误越是隐蔽复杂，取样对症的成功率也就越低。

247    对于简单易于重现的错误，重音应该落在´半”而不是´随机”上；此时，调试技巧和对代码以及其结构的熟识能派上大用场。

248    然而对于复杂的错误，重音则转向´随机”。

249    因为在这种情况下，众人多管齐下比少数人循序渐进要强的多即使这´少数人”的平均水平很高。

250    如果挖掘错误的途径不一，很难凭表面现象预测的话，并行纠错的效果就很明显了。

251    一个循序渐进的开发者可能一开始就选择了一条复杂的途径，当然他也可能一开始就选择到了简单的途径。

252    让我们换一个角度，如果软件发布的够及时，那么众人就可以多管齐下。

253    他们其中很可能有人立即就能找到一条快捷的途径，所以在极短的时间里就能修复问题。

254    项目的维护人员看到改进，于是发布新版本。

255    这样，那些通过其他困难途径探索同一个错误成因的人就可以在浪费掉更多时间之前停下来。

256    六 花香何曾随名去？

257    在研究了李纳斯的作法，并得到他何以成功的理论之后。

258    我决定在我的新项目中（当然没有Linux那么复杂和雄心勃勃）有意地尝试这些理论。

259    但是我首先要对popclient做大幅的重写和简化。