那个难题的提问只不过蛮反感性的：这两个方式，事实上反倒节约合作开发天数，所以越长期的工程项目，效用越明显。
那个反感性的课堂教学会带来两个很Goncelin的过敏反应: 你极难让两个唯独没或者说课堂教学过智能化试验的人去认知智能化试验的益处^^.
那个类似于如果你领了两个有天数管制的各项任务：全工程项目组需要跨过两条大江，到河南岸去。最合乎感性的方式是急忙带着工程项目组开始往南岸游。 所以老板娘看到你的工程项目组每晚都离南岸近一点儿也很高兴。但是最慢方式，其实是先造一艘。而没见过船的工程项目组，是非常难认知这一点儿的。
所以，我对完全没课堂教学过这三种方式的人只不过一般的讲法都是， 先不要得出结论，找个小的工程项目先实行下试一试 ^^.
好吧， 说明具体内容的原因之前，我来普及化一下一生三大错觉：
– 我的标识符没难题。
– 那个演算法跑起来了。
– 立刻就能发布了。
事实上两个应用软件技师高速成长操作过程大体上就是不断再次出现错觉然后被诚然的操作过程。 这种错觉不仅应用软件技师会出，返回控制技术工作岗位一段时间的控制技术管理人员也会再次出现。
一般而言你写着写着标识符突然没人在会后说， 我们急于今晚就收到去， 你就知道，的确没人又再次出现错觉了。
那些错觉再次出现的根源只不过所有应用计算机科学的书都讲过，最知名的书包括 《人月神话故事》 和 《The Psychology of Computer Programming》， 那些 70， 80 年代写的书里头的事例，每晚都能在很多公司里头找出。可是据我检视，读那些书对人的影响只不过比我想得小的多，大多数老司机还是真的被现实按在地上狠狠的摩擦以后，才能学会怎么做人。
我们能从两个方面来说为什么能节约天数：
– 对于两个技师来说，特别是比较初级的技师，再次出现这种错觉的原因是他没意识到， 把两个工程的实现标识符写完，平均来说仅仅是完成了 60%[1] 左右的进度，如果最开始写标识符的时候没考虑到标识符的可试验性， 那个比例可能会更少。
除非你的标识符极其简单 （比如你写个 hello world)， 你的标识符里头一定是有 bug 的， 只是 bug 的多少而已。那么难题就来了， 你怎么把那些 bug 找出来呢？
是的， 估计你已经想到了， 标识符审查和智能化试验。
综合来看，这三种做法是最高效率的找出大部分潜在 bug 的方式。 除开这三种方式以外，另外两个常用的就是人工黑盒试验。人工黑盒试验虽然不可少，但是相比智能化试验来说，少了能快速复用的特点。智能化试验属于高回报的投资， 一旦写好了以后， 就算改一行标识符都能重新跑一次，而人工试验相对来说远没这么灵活。
于是如果你的合作开发高效率 + 最高效率的去除 bug 的手段（标识符审查 + 智能化试验）。 从整个工程角度来说， 是最省天数的。
而如果你不去做标识符审查 + 智能化试验， 标识符写完黑盒测测就上线，不管覆盖率， 也不管 boundery , 看起来好像上线更快，整个工程只不过并没完成，你只是把难题推到了未来，于是我们就会看到这种情形：
如果把最后折腾来折腾去的把标识符搞稳定天数算进去，花的天数远比那个长。
当然很多公司可能搞着搞着，工程项目就取消了。
– 对于控制技术管理来说，code review + 和智能化试验是两个非常重要进度管理的工具。 因为你知道，如果两个技师告诉你， 我立刻就写完了。 这句话的置信度大体上为 50%, 就是说五五开，可能他确实做完了，也可能他已经做飞了。
那我们换种问法： 你的 code review 和自动化试验写完了吗？ 如果答案是 “是”， 那么大体上那个工程项目进度不会有什么难题了。
而对工程项目进度的正确信息，恰恰是合理分配资源最重要的依据。
记住： 两个试验过的应用软件，才是两个完成的应用软件。
最后，智能化试验并非两个黑和白的难题，事实上 两个覆盖不完全的智能化试验，效用也远远好于完全没智能化试验， 呃， 这句这么有哲理的话只不过是 Martin Fowler 大神说的 –Martin Fowler – Wikipedia。
所以老是说没天数的同学，那个不是借口哦 ^^
PS: 难题里头提到的 owner 休假一类的难题事实上工程管理的执行细节，那个和整个原理不相悖， 这块需要工程管理者花很大力气去慢慢梳理的， 比如之前在 Opera 每个 Module 除了owner 还需要两个 co owner， 同时还要避免把标识符审查变成标识符审判一类的难题 . 工程管理并不是立两个 FLAG 就完了对不对 ^^
[1] 那个因工程项目而已，我自己的经验平均在 60% 左右。
