★作者序★
在1995年版的序言中，我写道，
如果软件工程真的是一门工程学科，那么它是对经过验证的原则、技术、语言和工具的智慧的运用，用于有成本效益地创造和维护能够满足用户需求的软件。本书是有史以来本成册的软件工程原则集。原则是关于软件工程的基本原理、规则或假设，不管所选的技术、工具或语言是什么，其都有效。
26年后的今天，当我审视这201条原则时，我很高兴地宣告，几乎所有的原则都经受住了时间的考验，就像物理学中的基本原理一样。
然而，在这26年里，因为软件造成的问题相当之多。举几个例子：
★波音 737 MAX 机动特性增强系统（MCAS）的单点故障导致了两起空难，共造成 346 人死亡，调查结果是软件测试不彻底。
★全球范围的软件系统反复被勒索软件攻击，表明软件存在漏洞。
★一个无法预测且未被发现的溢出错误导致人类飞行控制员必须在发射后立即销毁阿丽亚娜 5 型运载火箭。
★火星气候轨道飞行器坠毁在火星上，原因是两个程序员关于变量的单位出现错误沟通：一个认为是磅，另一个认为是牛顿。
当桥梁或建筑物倒塌时，调查人员会尝试确定是什么地方出了问题。通常，是因为建筑商未能遵守建筑规范（即施工期间要遵循的一套规则或原则），或者检查员未能找到物理损坏的位置。当软件失败时，通常是因为软件工程组织没有遵守某个原则。
理解和实践一门学科的所有原则是否可以预防所有灾难？不是。它只会大大降低因你而导致灾难的可能性。正如亚历山大·波普所说，犯错是人之常情。只有通过犯错，我们才能学习，并制定新的原则。
在这本书中发表的大部分原则并非原创，很多是从软件工程从业者和研究者的著作中摘录而来的。这些人无私地和我们分享他们的经验、想法和智慧。我并不认为这201个原则是相互独立的。不像Boehm提出的7个基本软件工程原则，本书中的一些原则的组合可能蕴涵另一个原则。但我也不认为这201个原则中的某两个或某几个原则是100% 兼容的。俗话所说的，距离产生美和眼不见，心不烦都是真理，每个原则都可以应用在我们的生活中，但是它们却不能同时用来证明同一个决定是正确的。本书中包含的原则都是有效的，它们都能够用来提升软件工程的水平，但也许并不能将某些组合应用到同一个项目中。
本版中的原则与1995版中的原则相同。但是，你可能会对我的想法感兴趣，哪些仍然是正确的，哪些是我怀疑的。以下是我的想法：
对于第 2 章中介绍的一般原则，全部依然有效。一些额外说明如下。
★在原则 23～25 中，CASE这个词已经不流行了。今天，主要的软件开发工具支持问题跟踪、版本控制、虚拟机模拟、项目管理和调试。
★ 对于原则 28，我必须承认，在过去 26 年里，据我所知，没有一个为我工作过的软件工程师使用过形式化方法本身，尽管其中很多人还拥有高等数学学位，也就是说，他们在本质上，是知道如何以形式化的方式思考的。
对于第 3 章中介绍的需求工程原则，全部依然有效。一些额外说明如下。
★对于原则 40、41、43、45、47、48、49 和 54，在过去 26 年的大部分时间里，我一直致力于创业，在这种环境下，向客户提供一系列不断增大的小可行产品（MVP）以获取他们的反馈至关重要。我们只是在问题跟踪工具中以自然语言维护我们的需求，我们可以轻松地用优先级、目标版本、状态和注解对它们进行注释。当然，这正是原则 60 所体现的精神。
对于第 4 章中介绍的设计原则，全部依然有效。一些额外说明如下。
★对于原则 73，如今耦合和内聚变得不那么重要，已经被重用所取代。今天，我们通过从大量经过验证的组件库中选取许多组件来构建系统，并在必要时进行定制开发。库所依赖的框架倾向于鼓励弱耦合和强内聚，但我们不再需要考虑它了。
★ 原则 76 和 84 可能是所有原则中重要的原则。当然，我们在过去26年见证了框架的出现，它使软件重用变得更加容易。事实上，不再称之为重用，我们就简称其为软件开发。
★随着硬件变得更快、更便宜，原则 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
2021.9
★译者序★
我不是译者，仅是一名校对者。大家让我来写这篇译者序，盛情难却，无法推脱。本书英文版是我于2017年至2020年在百度举办代码的艺术训练营时使用的教材。这本书的内容深受训练营学员的好评。由于之前没有中文版，对于部分英文基础不太好的同学来说，阅读有些困难。在2019年年底，十多名代码的艺术训练营的毕业生自发组织起来，开始了对此书的翻译工作。我从2020年5月初开始校对工作，完成全书的校对，我花费了80～100小时。由此推断，负责翻译的同学花费了数倍于此的时间。非常感谢这些同学的无私付出！
初识本书英文版是在二十多年前。当时我还在清华大学读书，在老师的指导下做一个有一定规模的软件研发项目，在项目的研发过程中，遇到了不少软件工程方面的问题。于是在那一年，我阅读了大约十本软件工程方面的图书，包括Code Complete（《代码大全》）、Rapid Development、Programming Pearls（《编程珠玑》），等等。本书是我当时在清华大学图书馆里发现的宝贝。我必须说，此书对我的影响非常大，很多我现在经常提起的软件工程原则，都源于对这本书的阅读。
2006年我离开清华大学，到目前为止已经在工业界工作了十多年，先后就职于多家公司。我发现，虽然我们的软件研发规模和二十多年前相比有了很大的发展，但是在软件研发理念方面的进步还是太慢了。有太多的软件从业者，虽然已经工作多年，但对软件研发的基本理念和原则了解得还是不够多。根据我的多次调查，阅读超过两本真正的软件工程图书的人都非常少。很多软件工程师，仍然使用非常低效甚至是错误的方法在工作！
于是在2015年，我在百度开办了代码的艺术面授课程，其中就重点推荐了本书的英文版。而在2017年做代码的艺术训练营的时候，这本书就成了指定教材。为什么要选择这本书？因为它对软件工程的内容覆盖全面，且篇幅短小。对于一个短期培训班来说，如果选择类似《代码大全》这样的图书，阅读所需要的时间就有些太多了。在这种情况下，本书的英文版是一个性价比更高的选择。另外，我常常感觉，对于一个软件工程师，具备正确的意识比掌握具体的知识更重要。如果有正确的意识，即使不记得具体的知识点，也可以在需要的时候查阅相关资料，而反过来则不是这样的。
必须要说的是，本书的英文版写于1995年，距今已经有26年。这也是很多人担心的地方计算机技术发展得如此之快，这本书是不是已经过时了？但是，正如我在代码的艺术课程中对知识方法精神三者所做的对比，方法的变化速度远远慢于知识。尤其是在本次校对过程中，我惊奇地发现，书中真的可以说是过时的原则不足5个！是软件研发的方法变化太慢，还是书的内容太深刻？我想两者兼而有之。在此，我必须要对本书的作者Alan M. Davis致敬，并对书中所有原则的贡献者和历史上所有软件工程领域的大师们致敬！
在此，我要隆重介绍翻译本书的百度的同学们，他们是：叶王、马学翔、吴斌、王冰清、杨光、曾浩浩、李殿斌、甘璐、李子昂、肖远昊、贾儒、王莹、张苗、李双婕、荣文升。另外，经大家商定，将本书因翻译出版获得的稿酬全都捐赠给公益事业。
后，所有阅读本书的软件工程师和所有准备从事软件研发的同学们，我祝愿本书能助你们取得更大的成功！
章淼 博士 百度BFE团队技术负责人、百度代码规范委员会主席
2021年6月14日写于百度
书单推荐
