动态评估取舍

——高效程序员的45个习惯之习惯27

“性能、生产力、优雅、成本以及上市时间，在软件开发过程中都是至关重要的因素。每一项都必须达到最理想状态。”

可能曾经身处这样的团队：管理层和客户 将很大一部分注意力都放在应用的界面展示上。也有这样的团队，其客户认为性能表现非常重要。在团队中，你可能会发现，有这样一个开发主管或者架构师，他会 强调遵守“正确”的范式比其他任何事情都重要。对任何单个因素如此独断地强调，而不考虑它是否是项目成功的必要因素，必然导致灾难的发生。

强调性能的重要性情有可原，因为恶劣的 性能表现会让一个应用在市场上铩羽而归。然而，如果应用的性能已经足够好了，还有必要继续投入精力让其运行得更快一点吗？大概不用了吧。一个应用还有很多 其他方面的因素同样重要。与其花费时间去提升千分之一的性能表现，也许减少开发投入，降低成本，并尽快让应用程序上市销售更有价值。

举例来说，考虑一个必须要与远程 Windows 服务器进行通讯的 .NET Windows 应用程序。可以选择使用 .NET Remoting 技术或 Web Services 来实现这个功能。现在，针对使用 Web Services 的提议，有些开发者会说：“我们要在 Windows 之间进行通信，通常此类情况下，推荐使用 .NET Remoting 。而且， Web Services 很慢，我们会遇到性能问题。”嗯，一般来说确实是这样。

然而，在这个例子中，使用 Web Services 很容易开发。对 Web Services 的性能测试表明 XML 文档很小，并且相对应用程序自己的响应时间来讲，花在创建和解析 XML 上的时间几乎可以忽略不计。使用 Web Services 不但可以在短期内节省开发时间，且在此后团队被迫使用第三方提供的服务时， Web Services 也是个明智的选择。

Andy 说。。。

过犹不及
我曾经遇到这样一个客户，他们坚信可配置性的重要性，致使他们的应用有大概10 000个可配置变量。新增代码变得异常艰难，因为要花费大量时间来维护配置应用程序和数据库。但是他们坚信需要这种程度的灵活性，因为每个客户都有不同的需求，需要不同的设置。
可实际上，他们只有19个客户，而且预计将来也不会超过50个。他们并没有很好地去权衡。

考虑这样一个应用，从数据库中读取数据，并以表格方式显示。你可以使用一种优雅的、面向对象的方式，从数据库中取数据，创建对象，再将它们返回给 UI 层。在 UI 层中，你再从对象中拆分出数据，并组织为表格方式显示。除了看起来优雅之外，这样做还有什么好处吗？

也许你只需要让数据层返回一个 dataset 或数据集合，然后用表格显示这些数据即可。这样还可以避免对象创建和销毁所耗费的资源。如果需要的只是数据展示，为什么要创建对象去自找麻烦呢？不按书上说的 OO 方式来做，可以减少投入，同时获得性能上的提升。当然，这种方式有很多缺点，但问题的关键是要 多长个心眼儿 ，而不是总按照习惯的思路去解决问题。

总而言之，要想让应用成功，降低开发成本与缩短上市时间，二者的影响同样重要。由于计算机硬件价格日益便宜，处理速度日益加快，所以可在硬件上多投入以换取性能的提升，并将节省下来的时间放在应用的其他方面。

当然，这也不完全对。如果硬件需求非常庞大，需要一个巨大的计算机网格以及众多的支持人员才能维持其正常运转（比如类似 Google 那样的需求），那么考虑就要向天平的另一端倾斜了。

但是谁来最终判定性能表现已经足够好，或是应用的展现已经足够“炫”了呢？客户或是利益相关者必须进行评估，并做出相关决定（见第 45 页中 习惯 10 ）。如果团队认为性能上还有提升的空间，或者觉得可以让某些界面看起来更吸引人，那么就去咨询一下利益相关者，让他们决定应将重点放在哪里。

没有适宜所有状况的最佳解决方案。你必须对手上的问题进行评估，并选出最合适的解决方案。每个设计都是针对特定问题的 —— 只有明确地进行评估和权衡，才能得出更好的解决方案。

没有最佳解决方案 （No best solution）

动态评估权衡

考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了，就将注意力放在其他因素上。不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。

切身感受

即使不能面面俱到，你也应该觉得已经得到了最重要的东西 —— 客户认为有价值的特性。

平衡的艺术

• 如果现在投入额外的资源和精力，是为了将来可能得到的好处，要确认投入一定要得到回报（大部分情况下，是不会有回报的）。真正的高性能系统，从一开始设计时就在向这个方向努力。
• 过早的优化是万恶之源。
• 过去用过的解决方案对当前的问题可能适用，也可能不适用。不要事先预设结论，先看看现在是什么状况。