项目所能耗费的资源是有限的→设计的东西如果用不上，是对资源的浪费，会减少其他环节的投入→如果设计看不到实效，那么必须终止。
在探讨什么时候可以结束设计时，需要假设输入的需求是正确的。在此前提下，用不上的设计大致可以分为两类。
一是程度问题。设计如果关注某些细节，而这些细节自身却随着认知的深入而发生变化，那么与此相关的设计会变成无用的。
二是无意间扩散了需求的边界。比如，在看不到可移植性需求的情形下，为可移植性做了准备。这类设计的无用并不体现在技术上，而是体现在经济上。
对于程度问题，直接探讨终结尺度在哪里，很难找到令人信服的答案，因此我们可以像在6.2.3需求开发的终结一节中所做的一样，把这种程度问题转化为经济问题，这样更便于我们思考。
假使设计上考虑了一个因素，其所需要的开销是X，而不考虑这一要素，在后期发现并进行对应，其对应成本是Y，那么凡是会导致X＜Y的东西就都是需要在设计中预先澄清，而不能等待在编码中逐步澄清的。
从这个角度看，我们就可以列出设计的大致终结尺度。
●影响全局的由需求所定义的功能性要求和非功能性要求是否都被考虑到了。如性能目标是否能达成，国际化的需求是否被考虑到了，出错处理是否有统一的机制进行支持，是否需要复用既有代码，是否某部分要留给将来复用。对此，《代码大全》中提供了一份非常详细的Checklist，此外很多关于架构设计的书中也主要以此为着眼点进行展开，这里就不再进一步展开了。
●购买（或使用开源代码）还是自主开发这一维度是否被考虑到了。软件这一行业存在的历史越长，重复发明轮子的可能性越大。因此，是否购买（或者使用开源）而不是自己开发会成为一个越来越重要的问题。评价是否购买（或者使用开源），则可以进一步分解为：功能上能不能满足目标，经济上划算不划算，能否及时获得支持等。与这种考量关联最紧的则是估算，没有比较精确的估算就没法判断是赔还是赚。
●软件的可测性是否能够达成。软件是否可测本身更大程度上是由设计决定的，而不是由测试决定的。
●既有的设计是否支持对当前人员进行分工。这个维度事实上经常被忽略，但其本身则是一个比较明晰的，判断设计是否可以终止的尺度。假设说你的团队有10个人，那么只和1个人工作有关的部分可以不在设计时进行考虑，而与2人或2人以上相关的部分则要在设计时定义清楚接口。
●需求碎片化的应对。如果说是不停地往已有的代码中增加新特征，而每一个新特征都非常小，那这时候，设计会变得无限薄直至取消。
在对无意间扩散了需求边界这一问题进行具体分析之前，需要先看一对基本矛盾。(www.xing528.com)
软件设计自身最优化与项目本身资源有限、时间有限间的矛盾。有些书籍会堂而皇之的谈到：设计时需要考虑并发问题，需要考虑可移植性问题。这无疑是对的，但把问题过于单纯化了，事实上设计最优化并不是总有意义。
假设我们承认，开源之外，软件是商业的延续，那我们可以认为商业世界定义了软件的价值根源，而需求本身对这种价值根源的边界进行定义，设计本身并不能超出这种价值边界，否则就是种浪费。
这似乎有点抽象，我们还是用上面的例子来辅助说明。
假设我们要开发一款简单的分布式计算框架（服务器端负责管理任务，把任务分发到客户端，而客户端负责执行具体任务并把结果汇报给服务器端），这个时候是否使这个框架跨平台将对设计产生很大影响。
从软件自身最优化的角度看，支持跨平台是毋庸置疑的问题。但如果在需求之中看不到跨平台的要求，甚至说作为需求分析的结果一旦选定平台后，未来5年内，几乎完全看不到跨平台的需要，那么在设计层面究竟应该如何处理这一“技术问题”？
如果项目人力资源有限，时间有限，支持了这个，很可能就不能支持那个，或者就要增加开销。这真的是设计层面应该考虑的问题么？
在这一点上，我个人倾向于认为，这是需求问题。设计人员需要假设需求开发人员所做的需求开发是完善的，有疑问可以确认，但不能在设计层面随意扩张需求的边界。毕竟在大多时候，如果资源限定，完美是良好的大敌。
钱的贴现值
本书抽去了商业这一维度，因此这一章里有的地方变得有点含糊。但事实上如果把这里提出的问题转换为经济问题，就更容易理解一点。我们可以把支不支持跨平台这类问题同投资相类比。
如果我现在需要投入1000块钱，但可能在10年后才产生收益，那么如果使用5%的贴现率，只要10年后的投入不超过1628，就还是10年后再投入划算。设计也一样，如果晚做，没什么太大损失，那就没必要预先做了，浪费现时点的有限资源。
在经济学家眼里，现在的1元钱和1年后的1元钱是不等价的。如果贴现率是5%，那么现在的1元钱等于一年后的1.05元。
这和支不支持跨平台，支不支持并行这类问题很类似，与其说这是技术问题，倒不如说这是个经济问题。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
