欲求更好，常把好事变糟。
——李尔王1.4
有一个（有点）老的笑话，说一家美国公司向一家日本制造商订购片集成电路。规格说明中有次品率：片中只能有1片。几周过后订货到了：一个大盒子，里面装有数千片IC，还有一个小盒子，里面只装有10片IC。在小盒子上有一个标签，上面写着：“这些是次品”。
要是我们真的能这样控制质量就好了。但现实世界不会让我们制作出十分完美的产品，特别是不会有无错的软件。时间、技术和急躁都在合谋反对我们。
但是，这并不一定就让人气馁。如EdYourdon发表在IEEESoftware上的一篇文章[You95]所描述的，你可以训练你自己，编写出足够好的软件——对你的用户、对未来的维护者、对你自己内心的安宁来说足够好。你会发现，你变得更多产，而你的用户也会更加高兴。你也许还会发现，因为“孵化期”更短，你的程序实际上更好了。
在继续前进之前，我们需要对我们将要说的话进行限定。短语“足够好”并非意味着不整洁或制作糟糕的代码。所有系统都必须满足其用户的需求，才能取得成功。我们只是在宣扬，应该给用户以机会，让他们参与决定你所制作的东西何时已足够好。
让你的用户参与权衡
通常你是为别人编写软件。你常常需要记得从他们那里获取需求。但你是否常问他们，他们想要他们的软件有多好？有时候选择并不存在。如果你的工作对象是心脏起搏器、航天飞机、或是将被广泛传播的底层库，需求就会更苛刻，你的选择就更有限。但是，如果你的工作对象是全新的产品，你就会有不同的约束。市场人员有需要信守的承诺，最终用户也许已基于交付时间表制定了各种计划，而你的公司肯定有现金流方面的约束。无视这些用户的需求，一味地给程序增加新特性，或是一次又一次润饰代码，这不是有职业素养的做法。我们不是在提倡慌张：许诺不可能兑现的时间标度（timescale），为赶上最后期限而削减基本的工程内容，这些同样不是有职业素养的做法。
你所制作的系统的范围和质量应该作为系统需求的一部分规定下来。
提示7：
MakeQualityaRequirementsIssue
使质量成为需求问题
你常常会处在须要进行权衡的情形中。让人惊奇的是，许多用户宁愿在今天用上有一些“毛边”的软件，也不愿等待一年后的多媒体版本。许多预算吃紧的IT部门都会同意这样的说法。今天的了不起的软件常常比明天的完美软件更可取。如果你给用户某样东西，让他们及早使用，他们的反馈常常会把你引向更好的最终解决方案（参见曳光弹，48页）。
知道何时止步
在某些方面，编程就像是绘画。你从空白的画布和某些基本原材料开始，通过知识、艺术和技艺的结合去确定用前者做些什么。你勾画出全景，绘制背景，然后填入各种细节。你不时后退一步，用批判的眼光观察你的作品。常常，你会扔掉画布，重新再来。
但艺术家们会告诉你，如果你不懂得应何时止步，所有的辛苦劳作就会遭到毁坏。如果你一层又一层、细节复细节地叠加，绘画就会迷失在绘制之中。
不要因为过度修饰和过于求精而毁损完好的程序。继续前进，让你的代码凭着自己的质量站立一会儿。它也许不完美，但不用担心：它不可能完美（在第6章，页，我们将讨论在不完美的世界上开发代码的哲学）。
相关内容：
曳光弹
需求之坑
注重实效的团队
极大的期待
挑战：
考察你使用的软件工具和操作系统的制造商。你能否发现证据，表明这些公司安于发布他们知道不完美的软件吗？作为用户，你是会（1）等着他们清除所有bug，（2）拥有复杂的软件，并接受某些bug，还是会（3）选择缺陷较少的更简单的软件？
考虑模块化对软件交付的影响。与以模块化方式设计的系统相比，整体式（monolithic）软件要达到所需质量，花费的时间更多还是更少？你能找到一个商业案例吗？
预览时标签不可点收录于话题#个上一篇下一篇