软件质量的原则

原则1质量第一

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

原则2 质量在每个人眼中都不同
软件质量没有唯一的定义。对开发者来说，质量可能是优雅的设计或优雅的代码。对在紧张环境中工作的客户来说，质量可能是响应时间或高吞吐量。对成本敏感的项目来说，质量可能是低开发成本。对一些客户来说，质量可能是满足他们所有已知和未知的需求。这里的难题是，以上要求可能无法完全兼顾。当优化某人关注的质量时，可能会影响其他人关注的质量（这就是温伯格的“政治困境”原则）。项目必须确定各因素的优先级，并清晰地传达给所有相关方。

原则3 开发效率和质量密不可分
与质量之间存在明显的关系（开发效率可以用人月完成的代码行数或功能点数来度量）。对质量要求越高，开发效率就越低。对质量要求越低，开发效率就越高。越是强调提高开发效率，最终的质量就越低。贝尔实验室发现，在要求每千行代码有1～2个bug时，人月的效率通常为150～300行代码[参见Fleckenstein，W.，"Challenges in Software Development"，

尽管我们的行业中有一些表现不佳、包含bug，或者根本无法满足客户需求的软件系统的例子，但仍然有一些成功的例子。大型软件系统可以以非常高的质量构建，但价格昂贵：每行代码高达1000美元。例如，IBM为美国宇航局的航天飞机开发的机载飞行软件，总共约300万行代码，源于严谨的软件开发过程，产品发布后每万行代码中发现的错误少于一个。 作为软件开发人员，应该学习和了解已被验证、可以极大提高软件质量的方法。这些方法包括：让客户参与（见原则8）、原型设计（在全面开发之前验证需求；见原则11～13）、 保持设计简单（见原则67）、审查代码（见原则98）和雇用最优秀的人（见原则130和131）。作为客户，在追求卓越的同时，要意识到随之而来的高额成本。