豆瓣9.1分：软件开发的201个原则

给中国软件工程师的寄语

（节选）

致我的兄弟姐妹们：

和你们一样，我的职业生涯始于软件工程师，那是1975年，将近半个世纪之前。我认为我们在时间和国家方面的差异相当微不足道。所以，我像和我的朋友、我的同龄人一样与你交谈。

26 年后的今天，当我审视201 Principles of Software Development中的这201 条原则时，我很高兴地宣告，几乎所有的原则都经受住了时间的考验，就像物理学中的基本原理一样。

当你做软件架构设计或“抛出代码”时，不要忽视真正重要的事情。那是什么呢？是你的正直，这是你对自己的看法。如果有人要求你做一些你知道是错误的事情，你有义务阻止它。

软件工程是一个美妙的职业，它使你能够进入数百个以软件为支柱的专业领域。

“生生不息，繁荣昌盛。”好好享受！

201 Principles of Software Development 作者 Alan M.Davis

2021年9月

• 有些人重视代码编写技巧，而轻视软件开发的工程属性。
• 有些人在对需求缺乏真正理解的时候就急于编写代码。
• 有些人重视软件的功能实现，轻视文档对于软件开发和软件作品的重要性。

这些问题导致软件宕机、返工等质量问题时有发生。

01 了解基本原则的工程师，代码质量和开发效率更胜一筹

关于软件质量，业界普遍认为有3个决定性要素：人、过程和工具。如何基于这些要素提升代码的质量和开发效率，是软件工程研究者和实践者一直在努力的方向。

不同的公司有不同的文化背景，虽然开发不同的软件项目有不同的实践过程，但所要遵守的基本原则都是一样的。大量实践证明——

了解软件开发基本原则的工程师，比那些不了解基本原则的，编写代码的质量和开发效率明显胜出一筹。

原则 1 质量第一QUALITY IS #1

无论如何定义质量，客户都不会容忍低质量的产品。质量必须被量化，并建立可落地实施的机制，以促进和激励质量目标的达成。即使质量没达到要求，也要按时交付产品，这似乎是政治正确的行为，但这是短视的。从中长期来看，这样做是自杀。质量必须被放在首位，没有可商量的余地。Edward Yourdon 建议，当你被要求加快测试、忽视剩余的少量 bug、在设计或需求达成一致前就开始编码时，要直接说“不”。

原则 7 尽早把产品交给客户GIVE PRODUCTS TO CUSTOMERS EARLY

在需求阶段，无论你多么努力地试图去了解客户的需求，都不如给他们一个产品，让他们使用它，这是确定他们真实需求的最有效方法。如果遵循传统的瀑布式开发模型，那么在 99% 的开发资源已经耗尽之后，才会第一次向客户交付产品。如此一来，大部分的客户需求反馈将发生在资源耗尽之后。和以上方法相反，可在开发过程的早期构建一个快速而粗糙的原型。将这个原型交付给客户，收集反馈，然后编写需求规格说明并进行正规的开发。使用这种方法，当客户体验到产品的第一个版本时，只消耗了 5%～20% 的开发资源。如果原型包含合适的功能，就可以更好地理解和把握最有风险的客户需求，最终产品也就更有可能让客户满意。这有助于确保将剩余的资源用于开发正确的系统。

原则 17 只要可能，购买而非开发IF POSSIBLE, BUY INSTEAD OF BUILD

要降低不断上涨的软件开发成本和风险，最有效的方法就是，购买现成的软件，而不是自己从头开发。确实，现成的软件也许只能解决 75% 的问题。但考虑一下从头开发的选择吧：支付至少 10 倍于购买软件的费用，且要冒着超出预算 100% 且延期的风险（如果最后能够完成！），并且最终发现，它只能满足 75% 的预期。对一个客户来说，新的软件开发项目似乎最初总是令人兴奋的。开发团队也是“乐观的”，对“最终”解决方案充满了希望。但几乎很少有软件开发项目能够顺利运行。不断增加的成本通常会导致需求被缩减，最终研发出的软件可以满足的需求也许跟现成的软件差不多。作为一个开发者，应该复用尽可能多的软件。复用是“购买而非开发”原则在较小范围内的体现。

原则 22 技术优先于工具TECHNIQUE BEFORE TOOLS

一个没规矩的木匠使用了强大的工具，会变成一个危险的没规矩的木匠。一个没规矩的软件工程师使用了工具，会变成一个危险的没规矩的软件工程师。在使用工具前，你应该先要“有规矩”（即理解并遵循适当的软件开发方法）。当然，你也要了解如何使用工具，但这和“有规矩”相比是第二位的。我强烈建议，在投资于工具以对某项技术“自动化”之前，先手工验证这项技术，并说服自己和管理层：这项技术是可行的。在大多数情况下，如果一项技术在手工操作时不灵，那么在自动操作时也不灵。

原则 37 要承担责任TAKE RESPONSIBILITY

在所有工程学科中，如果一个设计失败，工程师会受到责备。因此，当一座大桥倒塌时，我们会问“工程师哪里做错了？”当一个软件失败了，工程师很少受到责备。如果他们被责备了，他们会回答，“肯定是编译器出错了”，或“我只是按照指定方法的 15 个步骤做的”，或“我的经理让我这么干的”，或“计划剩余的时间不够”。事实是，在任何工程学科中，用最好的方法也可能产出糟糕的设计，用最过时的方法也可能做出精致的设计。不要有任何借口。如果你是一个系统的开发者，把它做好是你的责任。要承担这个责任。要么做好，要么就压根不做。

02 一部亚马逊评分4.5分、豆瓣9.1分的领域经典著作，用【原则】讲透软件研发重要思想

对于一个软件工程师，具备正确的意识比掌握具体的知识更重要。如果有正确的意识，即使不记得具体的知识点，也可以在需要的时候查阅相关资料，而反过来则不是这样的。

畅销全球26年、软件开发领域经典著作201 Principles of Software Development，就是第一本以“原则”形式讲透软件研发重要思想，并影响无数从业者的传世宝典。

（亚马逊官网评分4.5分）

这本书沉淀了大量软件工程领域的理念及洞察，它们不是最新的，却是最稳定的那部分。书中每一个原则短小精悍，既独立成文，又相互联系，全面覆盖软件工程生命周期中的需求、设计、编码、测试和维护。

由于之前没有中文版，对于部分英文基础不太好的读者来说，阅读有些困难。在2019 年年底，十多名百度技术学院毕业生自发组织起来，开始了对此书的翻译工作。

03 《软件开发的201个原则》中文版正式出版

经过两年多的打磨，《软件开发的201个原则》中文版终于落地中国。

本书的英文版写于1995 年，距今已经有26 年。这也是很多人担心的地方——计算机技术发展得如此之快，这本书是不是已经过时了？正如译者所说，

是软件研发的方法变化太慢，还是书的内容太深刻？我想两者兼而有之。

内容介绍

本书汇总了软件工程原则。原则是关于软件工程的基本原理、规则或假设，不管所选的技术、工具或语言是什么，这些原则都有效。

全书共9 章，第1章为引言，后面8章将201个软件工程的原则划分为8个大的类别：一般原则、需求工程原则、设计原则、编码原则、测试原则、管理原则、产品保证原则和演变原则。

• 用【原则】讲透软件研发底层方法

从需求分析到产品演进，覆盖产品研发全流程。

• 首本实现【轻阅读】的研发工具书

201个原则独立成文，简练深刻，轻松阅读。

• 中文版采用【精装珍藏版】设计，向经典致敬。

一经上市，读者热情反馈：

献给每一位追求卓越的软件工程师

软件工程是一个美妙的职业，它使你能够进入数百个以软件为支柱的专业领域。

正如斯波克所说，“生生不息，繁荣昌盛。”

好好享受！

如果喜欢本文欢迎 在看丨留言丨分享至朋友圈 三连