质疑软件工厂

下面摘录《C++沉思录》里面一段：

    　我们很容易就会注意到：很多最成功的、最有名的软件最初是由少数人开发出来的。这些软件后来可能逐渐成长，然而，令人吃惊的是许多真正的赢家都是从小系统做起的。UNIX操作系统就是最好的例子，C编程语言也是。其他的例子还包括：电子表格、Basic和FORTRAN编程语言、MS-DOS和IBM的VM/370操作系统。VM/370尤其有趣，因为它完全是在IBM正规生产线之外发展起来的。尽管IBM多年来一直不提倡客户使用VM/370，但该操作系统仍牢牢占据IBM大型机的主流市场。

　　同样令人吃惊的是，很多大项目的最终结果却表现平平。我实在不愿意在公共场合指手画脚，但是我想你自己也应该能举出大量的例子来。

　　到底是什么使得大项目难以成功呢？我认为原因在于软件行业和其他很多行业不一样，软件制造的规模和经济效益不成正比。绝大多数称职的程序员能在一两个小时内写完一个100行的程序，而在大项目中通常每个程序员每天平均只写10行代码。

　　  开销

　　有些负面的经济效益是由于项目组成员之间相互交流需要大量时间。一旦项目组的成员多到不能同时坐在一张餐桌旁，交流上的开销问题就相当严重了。基于这一点，就必须要有某种正规的机制，保证每个项目成员对于其他人在做什么都了解得足够清楚，这样才能确保所有的部分最终能拼在一起。随着项目的扩大，这种机制将占用每个人更多的时间，同时每个人要了解的东西也会更多。

　　我们只需要看一下项目组成员是如何利用时间的，就会发现这些开销是多么明显：管理错误报告数据库；阅读、编写和回顾需求报告；参加会议；处理规范以及做除编程外的任何事情。

　　由于这些开销是有目共睹的，所以很多人正在寻找减少它的途径。起码到目前为止，我还没有见过什么有效的方法。这是个难题，我们可能没有办法解决。当项目达到一定规模时，尽管作了百般努力，所有的一切好像还是老出错；塔科马海峡大桥和“挑战者号”航天飞机灾难至今仍然历历在目。

　　 质疑软件工厂
有些人认为大项目的开销是在所难免的。这种态度的结果就是产生了有着过多管理开销的复杂系统。然而，更常见的情况是，这些所谓的管理最终不过是另一种经过精心组织的开销。开销还在，只是被放进干净的盒子和图表中，因此也更易于理解。有些人沉迷于这种开销。他们心安理得地那么做，就好像它是件“好事”——就好像这种开销真地能促进而不是阻碍高效的软件开发。毕竟，如果一定的管理和组织是有效的，那么更多的管理和组织就应该更有效。我猜想，这个想法给程序项目引进的纪律和组织，与为工厂厂房引进生产流水线一样。

　　我希望这些人错了。实际上我所接触过的软件工厂给我的感觉很不愉快。每个单独的功能都是一个巨大机器的一部分，“系统”控制一切，人也要遵从它。正是这种强硬的控制导致生产线成为劳资双方众多矛盾的焦点。

　　所幸的是，我并不认为软件只能朝这个方向发展。软件工厂忽视了编程和生产之间的本质区别。工厂是制造大量相同（或者基本相同）产品的地方。它讲求规模效益，在生产过程中充分利用了分工的优势。最近，它的目标已经变成了要完全消除人力劳动。相反，软件开发主要是要生产数目相对较少的、彼此完全不同的人造产品。这些产品可能在很多方面相似，但是如果太相似，开发工作就变成了机械的复制过程了，这可能用程序就能完成。因此，软件开发的理想环境应该不像工厂，而更像机械修理厂——在那里，熟练的技术工人可以利用手边所有可用的精密工具来尽可能地提高工作效率。

　　实际上，只要在能控制的范围内，程序员（当然指称职的）就总是争取让他们的机器代替自己做它们所能完成的机械工作。毕竟，机器擅长干这样的活儿，而人很容易产生厌倦情绪。

      随着项目规模越来越大，越来越难以描述，这种把程序员看成是手工艺人的观点也渐渐变得难以支持了。因此，我曾尝试描述应该如何将一个庞大的编程问题当作一系列较小的、相互独立的编程问题看待。为了做到这一点，我们首先必须把大系统中各个小项目之间存在的关系理顺，使得相关人员不必反复互相核查。换言之，我们需要项目之间有接口，这样，每个项目的成员几乎不需要关心接口之外的东西。这些接口应该像那些常用的子程序和数据结构的抽象一样成为程序员开发工具中的重要组成部分。