原则 1 质量第一
QUALITY IS #1
无论如何定义质量，客户都不会容忍低质量的产品。质量必须被量化，并建立可落地实施的机制，以促进和激励质量目标的达成。即使质量没达到要求，也要按时交付产品，这似乎是政治正确的行为， 但这是短视的。从中长期来看，这样做是自杀。质量必须被放在首位，没有可商量的余地。Edward Yourdon 建议，当你被要求加快测试、 忽视剩余的少量 bug、在设计或需求达成一致前就开始编码时，要直接说“不”。
原则 2 质量在每个人眼中都不同
QUALITY IS IN THE EYES OF THE BEHOLDER
软件质量没有唯一的定义。对开发者来说，质量可能是优雅的设 计或优雅的代码。对在紧张环境中工作的客户来说，质量可能是响应 时间或高吞吐量。对成本敏感的项目来说，质量可能是低开发成本。对一些客户来说，质量可能是满足他们所有已知和未知的需求。这里 的难题是，以上要求可能无法完全兼顾。当优化某人关注的质量时， 可能会影响其他人关注的质量（这就是温伯格的“政治困境”原则）。项目必须确定各因素的优先级，并清晰地传达给所有相关方。
原则 4 高质量软件是可以实现的
HIGH-QUALITY SOFTWARE IS POSSIBLE
尽管我们的行业中有一些表现不佳、包含 bug，或者根本无法满 足客户需求的软件系统的例子，但仍然有一些成功的例子。大型软件 系统可以以非常高的质量构建，但价格昂贵：每行代码高达 1000 美 元。例如，IBM 为美国宇航局的航天飞机开发的机载飞行软件，总共 约 300 万行代码，源于严谨的软件开发过程，产品发布后每万行代码中发现的错误少于一个。作为软件开发人员，应该学习和了解已被验证、可以极大提高软件质量的方法。这些方法包括：让客户参与（见原则 8）、原型设计 （在全面开发之前验证需求；见原则 11～13）、保持设计简单（见原 则 67）、审查代码（见原则 98）和雇用最优秀的人（见原则 130 和 131）。作为客户，在追求卓越的同时，要意识到随之而来的高额成本。
原则 5 不要试图通过改进软件实现高质量
DON’T TRY TO RETROFIT QUALITY
质量无法通过软件的改进来获得。这适用于质量的任何定义：可 维护性、可靠性、适应性、可测试性、安全性等。即使我们在开发过 程中十分努力，使软件具备高质量也是十分不易的。如果我们不努力， 又怎么可能期望获得高质量呢？这就是绝不能将“一次性原型”转换 成产品的主要原因（见原则 11）。
原则 7 尽早把产品交给客户
GIVE PRODUCTS TO CUSTOMERS EARLY
在需求阶段，无论你多么努力地试图去了解客户的需求，都不如 给他们一个产品，让他们使用它，这是确定他们真实需求的最有效方 法。如果遵循传统的瀑布式开发模型，那么在 99% 的开发资源已经 耗尽之后，才会第一次向客户交付产品。如此一来，大部分的客户需 求反馈将发生在资源耗尽之后。和以上方法相反，可在开发过程的早期构建一个快速而粗糙的原 型。将这个原型交付给客户，收集反馈，然后编写需求规格说明并进 行正规的开发。使用这种方法，当客户体验到产品的第一个版本时， 只消耗了 5%～20% 的开发资源。如果原型包含合适的功能，就可以 更好地理解和把握最有风险的客户需求，最终产品也就更有可能让客 户满意。这有助于确保将剩余的资源用于开发正确的系统。
原则 9 促使开发者与客户的目标一致
ALIGN INCENTIVES FOR DEVELOPER AND CUSTOMER
项目经常会因为客户和开发人员的目标不同（或不兼容）而失败。一个简单的案例是，客户希望在特定日期前获得特性 1、2、3，而开 发人员希望最大化营收或利润。为了最大化营收，开发人员可能会尝 试完整地开发这三个特性，即使会导致项目延期。与此同时，客户可 能宁愿放弃其中一个特性的一部分功能，只要能按时交付其他特性。为使双方的目标达成一致，有如下方法：（1） 按优先级对需求排序（见原则 50），以便开发人员了解它 们的相对重要性。（2） 根据需求的优先级奖励开发人员（例如，所有高优先级的 需求必须完成；每完成一个中优先级的需求，开发人员可 获得一些额外的小奖励；每完成一个低优先级的需求，可 获得的奖励非常小）。（3） 对逾期交付实行严厉的处罚。
原则 13 要快速地开发一次性原型
BUILD THROWAWAY PROTOTYPES QUICKLY
如果你已经决定开发一次性原型，那么就要用最快的方式。不用担心质量。可使用“一页纸”的需求规格说明。不用担心设计或编码中的文档。可以使用任何工具。可以使用任何编程语言，只要能够方 便程序的快速开发。不用担心编程语言的可维护性。
原则 15 看到越多，需要越多
THE MORE SEEN, THE MORE NEEDED
在软件行业，一次次见证了：提供给用户的功能（或性能）越多， 用户想要的功能（或性能）就越多。当然，这与原则 7（尽早把产品 交给客户）、原则 14（渐进地扩展系统）、原则 185（软件会持续变化） 以及原则 201（系统的存在促进了演变）互相支持。但更重要的是， 你必须为不可避免的情况做好准备。在管理和工程处理流程的每个方 面都应该做好准备，一旦用户看到产品，他们就会想要更多的东西。这意味着，所产生的每个文档都应该以有利于更改的方式进行存 储和组织。这意味着，配置管理流程（见原则 174）必须在距离交付很长时间之前就就位。这也意味着，在软件部署后不久，你就应该准备好，以应对用户口头或书面请求的冲击。这还意味着，你选择的设计方案应使容量、输入速率和功能都很容易变更。
原则 17 只要可能，购买而非开发
IF POSSIBLE, BUY INSTEAD OF BUILD
要降低不断上涨的软件开发成本和风险，最有效的方法就是，购买现成的软件，而不是自己从头开发。确实，现成的软件也许只能解 决 75% 的问题。但考虑一下从头开发的选择吧：支付至少 10 倍于购买软件的费用，且要冒着超出预算 100% 且延期的风险（如果最后能 够完成！），并且最终发现，它只能满足 75% 的预期。对一个客户来说，新的软件开发项目似乎最初总是令人兴奋的。开发团队也是“乐观的”，对“最终”解决方案充满了希望。但几乎 很少有软件开发项目能够顺利运行。不断增加的成本通常会导致需求 被缩减，最终研发出的软件可以满足的需求也许跟现成的软件差不多。作为一个开发者，应该复用尽可能多的软件。复用是“购买而非开发” 原则在较小范围内的体现。可参考原则 84。
原则 22 技术优先于工具
TECHNIQUE BEFORE TOOLS
一个没规矩的木匠使用了强大的工具，会变成一个危险的没规矩 的木匠。一个没规矩的软件工程师使用了工具，会变成一个危险的没 规矩的软件工程师。在使用工具前，你应该先要“有规矩”（即理解 并遵循适当的软件开发方法）。当然，你也要了解如何使用工具，但 这和“有规矩”相比是第二位的。我强烈建议，在投资于工具以对某项技术“自动化”之前，先 手工验证这项技术，并说服自己和管理层：这项技术是可行的。在 大多数情况下，如果一项技术在手工操作时不灵，那么在自动操作 时也不灵。
原则 30 跟风要小心
FOLLOW THE LEMMINGS WITH CARE
即使有五千万人说傻话，那仍然是傻话。
安那托尔·佛朗士（Anatole France）
大家都做的事情，对你来说也不一定是正确的。也许它是正确的， 但你也应该评估它对你所处环境的适用性。这样的例子包括：面向对 象，软件度量（见原则 142、143、149、150 和 151），软件复用（见 原则 84），过程成熟度（见原则 163），计算机辅助软件工程（CASE， 见原则 22 至 25），原型设计（见原则 11、12、13、42）。在所有案 例中，以上这些方法都提供了非常积极的帮助，体现在提高质量、降 低成本、提高用户满意度等方面。然而，这些好处只在它们能发挥作 用的组织中才会显现出来。尽管回报显著，但是它们的作用常常被过 度宣传，其实它们并不是那么必然或通用。当你学习“新”技术时，不要轻易接受与之相关的不可避免的 炒作（见原则 129）。要仔细阅读，理性考虑它的收益和风险。在大 规模应用之前要进行试验。但同时也绝对不要忽略“新”技术（见 原则 31）。
Davis, A., "Software Lemmingineering," IEEE Software, 10, 6 (September 1993), pp. 79-81, 84.
类似的原则还有很多，以上内容摘自《201 Principles of Software Development》中文版，书名是《软件开发的201个原则》。
