原则 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
大家都做的事情，对你来说也不一定是正确的。也许它是正确的， 但你也应该评估它对你所处环境的适用性。这样的例子包括：面向对 象，软件度量（见原则 142、143、149、150 和 151），软件复用（见 原则 84），过程成熟度（见原则 163），计算机辅助软件工程（CASE， 见原则 22 至 25），原型设计（见原则 11、12、13、42）。在所有案 例中，以上这些方法都提供了非常积极的帮助，体现在提高质量、降 低成本、提高用户满意度等方面。然而，这些好处只在它们能发挥作 用的组织中才会显现出来。尽管回报显著，但是它们的作用常常被过 度宣传，其实它们并不是那么必然或通用。当你学习“新”技术时，不要轻易接受与之相关的不可避免的 炒作（见原则 129）。要仔细阅读，理性考虑它的收益和风险。在大 规模应用之前要进行试验。但同时也绝对不要忽略“新”技术（见 原则 31）。
类似的原则还有很多，以上内容摘自《201 Principles of Software Development》中文版《软件开发的201个原则》
