重新理解“软件工程”

前言 一次偶然的机会让我知道了《软件工艺》这本书，在读这本书之前我从来没有听过“软件工艺”这个词，这是一本 2004 年出版的书，不过让我吃惊的是书中说的很多思想，引发的思考就算拿到 10 多年后的今天依然不过时。所以在激动感慨之余，我写下自己的总结和感想，希望和大家分享。如果有机会希望大家去阅读本书，我相信你一定会受益匪浅的。   什么是"软件工艺"我会在下一篇来介绍，本篇文章我想说说为什么要把软件开发项目叫做“软件工程”。

什么是软件工程

在分析"软件工程"与"软件工艺"他们不同之前，我们先看看软件工程到底是如何定义的，如果你是一个软件从业者，相信这个词一定耳熟能详，不过他的来历可能并不是很多人都清楚。让我们来重新认识一下“软件工程”吧。

在 1968 年的一次 NATO 会议上，软件专家们提出了“软件危机”的概念，并指出：对于大型的、要求高质量的软件应用程序来说，软件工程是使其脱离危机的最佳途径。此后相当长的一段时间里，美国国防部的软件需求一致主宰着软件工程的主流论调。

这是软件工程的来历。那么什么是软件工程呢？来看看书中的定义，让我们感受一下：

采用一种有组织、有纪律可计量的方式来的开发、使用及维护软件。也即在软件领域中对工程学的采用。  

从定义可以看到“有组织、有纪律，可计量”，这明显是工程学的要求，不仅仅是软件领域。工程管理的思想是从制造业而来，他们传承自泰勒的科学管理体系，套用到软件领域有如下几个方面希望：

管理方面  

• 大批“平均水平”的程序员，通过管理达到高效的工作和高质量产出。

• 管理者是了解“最佳途径”的唯一人选，雇员照着做就行。

系统工程  

• 精细分工  

希望每一个步骤都能够更专业，需求分析，用户交互设计，系统架构，编码，测试，实施维护等。带来的问题是每一个步骤间的等待，信息传递的失真，不同岗位的地位差别。最后维护部分的员工可能是最卑微同时可能是最不了解项目的那个人。带来的隐患可能是引发各种项目事故。

• 生产线方式  

生产线的方式是精细分工的实现，精细分工导致各个阶段需要生产线方式来集成起来。但是传统制造业用生产线是因为知识包含在机器里面，人通过培训学习操作机器就可以。而软件工程希望通过流程弥补经验的缺失，让平庸的团队也能够交付大型项目。不过真的能吗?我想你内心已经有了答案。

适用的场景  

看了上面对软件工程的描述，到底哪些项目适合软件工程的方式呢？来看一下书中的例子：

• 为航天飞机编写软件的过程  

曾经能够达到最后三个版本中(平均代码长度 420000 行)，每个版本只有一个错误。最后 11 个版本中，一共有 17 个错误，而同等复杂度的商业软件将会有 5000 个错误

• 弹道导弹设计的软件

• 医疗设备

• 新型飞机的电子设备

总结

最开始的软件研发是在特定硬件上面运行软件的大型项目，例如导弹研制，火箭研发。软件只是众多流程的一部分，在它前面有很多其他工作，例如硬件的设计和制造。在这些步骤中，软件一开始是没有测试环境的，他必须通过架构的缜密设计来保证其最后实现的有效性，这期间会有详细的文档和多种形式的审查来避免出错，最后编码往往是在项目尾声，而这时候不用很高的技术要求，只要求按照详细规格说明书将代码输入到特定硬件上运行就可以，整个过程是高度可控并可预测的。能够看得出来，这类项目试错成本都很高，不仅费用高昂而且人命关天，所以通过工程化来规范和越睡会更合理。但是现代软件开发，规模更小，试错成本很低，需求变化却很快，需求模糊，那笨重的软件工程明显就跟不上节奏了。软件工艺的思想能否带来不同的灵感呢？让我们来看看下一篇对软件工艺的解读吧。

原文引用

• [重新理解“软件工程”]