有一个老笑话就是这样的：一个美国公司向一个日本制造商订购了10万个集成电路。规格说明书规定缺陷率只能是一万分之一。几个星期后，订单完成了，货物交付了。除了一个大盒子的芯片，还有一个小盒子，里面装着十个带有标签的芯片，上面写着“这些是有问题的”。
要是我们能像那样控制质量就好了。但是现实世界不允许我们生产太多真正完美的产品，尤其是没有任何错误的软件。时间、技术和急躁都在与我们作对。
【资料图】
然而，不要过于灰心。正如Edward Yourdon在IEEE Software杂志上的一篇文章中所述，“足够好的软件是最好的软件”，你可以训练自己编写足够好的软件 - 对用户和未来的维护者来说足够好，只要它带给你内心的平静。你会发现自己变得更加高效，用户也会更加满意。而且，让你更加高兴的可能是，更短的开发周期实际上可以改善你的程序。
在进一步讨论之前，我们需要在我们即将讨论的内容上设定一些界限。“足够好”并不意味着匆忙或质量低劣的代码。所有系统必须满足用户的要求才能被认为是完整的，并且必须达到基本的性能、隐私和安全标准。从用户的角度来看，你正在做的是否足够好？最好给用户一个参与评估的机会。
在权衡中涉及用户。
通常情况下，你是为他人开发软件，你总是记得要识别他们的需求。但你是否经常问他们，他们希望软件有多好？实际上，很多时候没有选择。如果你的软件用于心脏起搏器、航天器或广泛使用的库，那么要求会更严格，你的选择会受到限制。
然而，如果你正在开发一个全新的产品，那么限制将会不同 - 市场已经做出了承诺，最终用户可能已经根据交付计划进行了规划，公司肯定会受到现金流的限制。不考虑用户需求，任意地将功能堆叠到程序中，一遍又一遍地打磨代码，这些都是不专业的行为。轻率当然是不可取的，比如承诺一个无法实现的时间表，然后为了满足截止日期而做出必要的妥协 - 这也是不专业的。
对于你创造的系统，其应用领域和要达到的质量水平必须作为系统需求的一部分进行讨论。
（程序员的软技能：/course/6034346）
将质量要求视为需求。
人们常常面临需要权衡的情况。令人惊讶的是，很多用户宁愿今天使用一个不太完善的软件，而不愿再等一年，等到一个经过打磨、功能完整的版本（而实际上，一年后他们真正需要的可能完全不同）。许多预算受限的IT部门可能会同意这种观点。与你心中明天的完美软件相比，今天相当不错的软件通常更受欢迎。如果你让用户提前尝试一下，他们的反馈经常会引导你找到更好的最终解决方案。
知道何时停止。
在某种程度上，编程就像绘画。你从一块空白的画布开始，只有一些非常基本的材料。你将科学、艺术和工艺融合在一起，决定如何处理这些材料。你勾画出一个大致的形状，填充底色，然后添加细节。你不断以批判的眼光审查你完成的工作。你可能偶尔会放弃一个画布，重新开始。
但艺术家会告诉你，如果你不知道何时停下，你所有的努力都会白费。如果你不断地堆积细节，绘画就会在颜料中迷失。
不要让过度的完善侵蚀一个运行良好的程序。继续前进，让代码在需要的地方停留一段时间。它可能不是完美的，没关系 - 它不必永远完美。
（程序员的软技能：/course/6034346）
