作者序
在1995年版的序言中，我写道，
如果软件工程真的是一门工程学科，那么它是对经过验证的原则、技术、语言和工具的智慧的运用，用于有成本效益地创造和维护能够满足用户需求的软件。本书是有史以来第一本成册的软件工程原则集。[1]原则是关于软件工程的基本原理、规则或假设，不管所选的技术、工具或语言是什么，其都有效。
27 年后的今天，当我审视这 201 条原则时，我很高兴地宣告，几乎所有的原则都经受住了时间的考验，就像物理学中的基本原理一样。
然而，在这27年里，因为软件造成的问题相当之多。举几个例子：
■ 波音737MAX机动特性增强系统（MCAS）的单点故障导致了两起空难，共造成 346 人死亡，调查结果是软件测试不彻底。
■ 全球范围的软件系统反复被勒索软件攻击，表明软件存在漏洞。
■ 一个无法预测且未被发现的溢出错误导致人类飞行控制员必须在发射后立即销毁阿丽亚娜 5 型运载火箭。
■ 火星气候轨道飞行器坠毁在火星上，原因是两个程序员关于变量的单位出现沟通错误：一个认为是磅，另一个认为是牛顿。
当桥梁或建筑物倒塌时，调查人员会尝试确定是什么地方出了问题。通常，是因为建筑商未能遵守建筑规范（即施工期间要遵循的一套规则或原则），或者检查员未能找到物理损坏的位置。当软件出故障时，通常是因为软件工程组织没有遵守某个原则。[2]
理解和实践一门学科的所有原则是否可以预防所有灾难？绝对不是。它只会大大降低因你而导致灾难的可能性。正如亚历山大·波普所说，“犯错是人之常情。”只有通过犯错，我们才能学习，并制定新的原则。
在这本书中发表的大部分原则并非原创，很多是从软件工程从业者和研究者的著作中摘录而来的。这些人无私地和我们分享他们的经验、想法和智慧。我并不认为这201个原则是相互独立的。不像Boehm提出的7个“基本”软件工程原则，本书中的一些原则的组合可能蕴涵另一个原则。但我也不认为这201个原则中的某两个或某几个原则是100%兼容的。俗话所说的，“距离产生美”和“眼不见，心不烦”都是真理，每个原则都可以应用在我们的生活中，但是它们却不能同时用来证明同一个决定是正确的。本书中包含的原则都是有效的，它们都能够用来提升软件工程的水平，但也许并不能将某些组合应用到同一个项目中。
本版中的原则与1995版中的原则相同。但是，你可能会对我的想法感兴趣，哪些仍然是绝对正确的，哪些是我怀疑的。以下是我的想法。
对于第 2 章中介绍的一般原则，全部依然有效。一些额外说明如下。
■ 在原则 23～25 中，“CASE”这个词已经不流行了。今天，主要的软件开发工具支持问题跟踪、版本控制、虚拟机模拟、项目管理和调试。
■ 对于原则 28，我必须承认，在过去27年里，据我所知，没有一个为我工作过的软件工程师使用过形式化方法本身，尽管其中很多人还拥有高级数学学位，也就是说，他们在本质上其实是知道如何以形式化的方式思考的。
对于第3章中介绍的需求工程原则，全部依然有效。一些额外说明如下。
■ 对于原则 40、41、43、45、47、48、49和 54，在过去 27年的大部分时间里，我一直致力于创业，在这种环境下，向客户提供一系列不断增加的最小可行产品（MVP）以获取他们的反馈至关重要。我们只是在问题跟踪工具中以自然语言维护我们的需求，我们可以轻松地用优先级、目标版本、状态和注解对它们进行注释。当然，这正是原则 60 所体现的精神。
对于第 4章中介绍的设计原则，全部依然有效。一些额外说明如下。
■ 对于原则 73，如今耦合和内聚变得不那么重要，已经被重用所取代。今天，我们通过从大量经过验证的组件库中选取组件来构建系统，并在必要时进行定制开发。库所依赖的框架倾向于鼓励弱耦合和强内聚，但我们不再需要考虑它了。
■ 原则76和84可能是所有原则中最重要的原则。当然，我们在过去 27 年见证了框架的出现，它使软件重用变得更加容易。事实上，不再称之为重用，我们就简称其为软件开发。
■ 随着硬件变得更快、更便宜，原则 79 变得越来越不重要。
■ 原则 80，如果实施更正，可能已经避免了阿丽亚娜 5 型火箭的灾难。
对于第 5 章中介绍的编码原则，全部依然有效。一些额外说明如下。
■ 对于原则94，我认为现代软件工程师不需要再担心这个了。
■ 对于原则96，这仍然是我的最爱之一。我一直在实践它，我的软件工程师同事认为我疯了。
对于第6章中介绍的测试原则，全部依然有效。一些额外说明如下。
■ 对于原则 120，谨以此向我的朋友汤姆·麦克凯布致以崇高的敬意，我认为他的指标已经不再有用。我知道没有人再使用它了。对不起，汤姆。
■ 对于原则124，所有现代测试工具都会自动执行此操作。
对于第 7 章中介绍的管理原则，全部依然有效。一些额外说明如下。
■ 对于原则129、131、132、133、134、135、137、138、140、142和147，如果你不相信这些，请不要成为经理。
■ 对于原则 168，对当今的大多数应用程序来说不是一个真正的问题。
对于第8章中介绍的产品保证原则，全部依然有效。一些额外说明如下。
■ 我最近托运了一辆自行车，几乎横跨了整个国家，当收到时，货物箱子损坏而且很多零件不见了。我联系制造商购买缺少的零件，他们告诉我，每辆自行车都不同，虽然我有型号，但每辆自行车的每个实例都是不同的。不仅如此，他们也没有记录每辆运输的自行车组装了哪些零件，因此他们不可能将丢失的零件寄给我。我很震惊。软件配置管理（如今，通常称为版本控制）应该跟踪每个组件的每个版本，以及组件版本的哪些组合构成了可行的系统，以及哪些客户拥有哪些可行的版本。我认为这应该是一个新的原则。
■ 对于原则 176 和 177，可能不再那么重要了。
对于第 9 章中介绍的演变原则，全部依然有效。
Alan M.Davis
[1] Winston Royce和Barry Boehm发表了软件工程原则方面最早的两篇论文，分别包含5个原则和7个原则[ROY70，BOE83]。
[2] 由于软件并非实体的，并且不会因与元素的交互而退化，我能想到的软件“物理退化”的唯一等价物是它在经历维护时变得越来越不可靠（无论是修正还是增强）。但是，执行维护的软件工程组织应该遵守软件工程的基本原则。