【IT168 技术文章】

　　"软件工程"是指我们在学校中学习的那些理论，经过多年的开发实践和技术交流中，我们不断在对传统的软件工程理论进行反思。在将软件开发分为3个阶段（需求分析、设计和编程）时，我们很自然地会提出一个问题，"软件开发者应该继续提高专业化程度吗？"毕竟，劳动的分工是工业革命的基础。正是由于将制造业分解成多个精确定义的小任务，一组工人的生产率才能得到突飞猛进。所以，我们想当然地认为：对于软件开发，这种"专业化"的方式也将同样有效。

　　这看起来显而易见，不是吗？让一些人成为专业的分析师，专门获取和记录用户的需求；让一些人成为设计师，负责从需求文档制造出设计规格文档；程序员则负责根据设计规格进行编码。很显然，这应该是一种更加高效的工作方式，不是吗？答案是否定的。

　　问题的分析

　　1. 忽略了沟通的成本

　　同一件任务被切分而成的小步骤越多，人与人之间传递信息所耗费的时间总量就越多。因此，在不需要大量交流工作中（例如制造业中的很多体力劳动）中，流水式生产线能够运转得很好；但在需要大量交流的脑力劳动（尤其是软件开发）中，这种方式一败涂地。

　　软件开发的绝大部分工作都是在团队成员的头脑中完成的。如果要强迫每个人专门从事某一项特定的工作，那么任何一个简单的项目都会需要传递更多额外的中间产品。每一次的传递都可能带来潜在的错误和缺陷，因此，每次传递都是相当昂贵的。没错，如果要求每个人都编写大量的文档，以降低其他人作出错误理解或假设的风险，我们当然可以将"由于交流而出错"的可能性降到最低。但是，"编写更多文档"的工作量同样也是计算在项目的开销中的。正如Fred Brooks所指出的，如果决定某项任务成败的因素是项目组成员之间的交流效率，那么加入更多的人就只会延缓项目的进展。

　　当同一个开发者对需求、设计和源代码都有着深入的理解时，软件开发就能够获得最好的效果。Steven Levy所采访的所有黑客都是独自进行设计和编码的。在对"影响了（个人）计算机产业的19个程序员"的采访中，Susan Lammers也提到了同样的现象。在这些伟大的程序员中，没有任何一个使用过软件工程风格的分工方式，他们通常都是独自深入整个设计和编码工作。很有趣的是，他们几乎每个人都有自己独特的工作风格。

　　2. 导致混乱

　　将传统的劳动分工强加于软件开发，结果是导致分析师、设计师、程序员、测试员、用户界面专家、文档工程师、技术支持工程师之间不断地传递信息。过多的交流极大地降低了效率，项目被不断拖延。任何一点变化出现时，都必须将信息沿整条开发链传递下去，并导致一片混乱。项目结束后不久，软件就变成了"遗留系统"，因为没人清楚它究竟时如何工作的。

　　软件工程对技术进行人为的细分，结果导致任何一个人都不可能了解整个应用程序。软件工程解决这个问题的办法不是再开发者之间进行交叉培训，让他们了解全局，而是不断强调文档的神话－良好的文档能让任何人理解整个应用程序。不幸的是，尽管文档能够很好地记录软件中的抉择和协议，但却无法有效地保留、传递关于具体问题的详细信息，而这些具体细微的知识才是最重要的。

　　软件工程的另一个贻害是：它把文档搞得声名狼藉。很多项目实际上根本没有任何文档，因为年轻的开发者们本能地拒斥这种"软件工程的产物"。

　　3. 缺乏科学量化的手段

　　"科学管理"用科学取代了经验法则。在"科学管理"的方法中，数字支配一切。如果要改进什么东西，你首先必须对它进行度量。如果什么东西不能被度量，就不可能对它进行改进。管理者知道一切。任何工作都必然有一条非常好的途径。

　　所以，看到软件工程师发明了许许多多软件开发的度量方法，我们也就不会觉得太惊奇了。甚至，由"科学管理"带来的"时间－动作研究"（time-and-motion study）已经被用于研究软件的使用情况了。在某些特定的问题上，人们已经规定出一些定量法则，例如将光标移动到按钮上需要多长时间（Fitts 法则）、在概率相当的行为之间作出选择需要多长时间（Hick法则）等等。