第三章 根除低下的效率

    为什么？为什么！为什么项目经理会做这么愚蠢的决定，到处改动代码，结果却毫无起色？不仅仅是项目经理，虽然他们在提升性能方面还算是个能手——构架师、团队负责人以及其他一干人等在肆意挥霍大家的生命，做些无用功，做毫无头绪的工作，却不能让我们提供真正有价值的东西。是什么原因造成这样的闹剧？很简单。我们在不断优化——优化我们本身一塌糊涂的东西。

    是哪些白痴在优化他们本身就种下的祸根？就是你们这些人。你，你的朋友，你的老板。这些人都是出于善意却铺就了通向灾难的道路。我们在优化原本错误的做法却成就了最终错误的结果。这样做是错误的，也是可以避免的。但是，同志们，为什么你害怕一点点的努力会造成蓄意的恶行？

    你想知道答案

    我还是少找你的麻烦，省去些长篇累牍，先给你个答案——向着期望的结果进行优化。这听起来超简单也很显然，但人们总是自以为是地误入歧途，我还是一字一句地逐个讲来。

    优化定量测定一下你们现在做得有多好，分析一下你们怎样能做得更好，改变一下方式，然后再测度一下。微软对于优化很有一手，但是我们只度量易于掌控的事而不是探究问题真正出在哪里。所以，优化后却得到一个错误的结果。可以在第2章的“你怎么度量你自己”中了解到更多内容。

    意图意图要明确。为优化而优化是纯粹自我满足的表现——不要这样丢人现眼哦。相反，三思，再三思。弄明白你要做什么。专业一些，清醒一些。

    期望把心思放在你想要什么，而不是你不想要什么。这里有个误区。人们总是围着问题谈优化而不是解决方法。官僚主义及慢速的软件都是由此而来。他们把精力放在如何驾驭人或代码以防止有错误行为。他们应该把精力放在如何使正确的行为更快更容易上，然后发现其中的异常现象。

    结果绝对不要对某个步骤或算法单独分割进行优化。相反，对你期望的最终结果进行优化。我们都体验过局部优化而非总体优化的影响。它扼杀了我们的效率及创新能力，它将摧毁我们的星球。但三两下之后，人们往往就不能摆脱眼前的问题而去顾及他们真正想要的结果。

    你能明白什么时候你会伪优化吗？让我们看些例子，再核实一下。

    作者注：我意识到，在一个专栏内同时谈论优化代码及优化人的问题会有点混乱。我无法抗拒这么做，因为这二者间千丝万缕的关系正与日俱增。如果对你来说分清二者关系并不难，那就只要关注一下你所在意的问题。

    我想，我可以处理

    你怎么处理代码的运行时错误？在没有错误出现的情况下你的代码运行有多快？在一次并无错误出现的操作过程中软件运行是顺畅还是经常卡？以最简易最快速的方式完成代码运行有80%的可能，而不是20%。但是，这并不意味着你在错误处理上蒙混过关，你只是没有对它进行优化。要相信，你的代码将以零错误运行，要让它的运行速度更快。对零错误加以验证，确保结果正确。要相信但也要验证。

    同样，你是怎么处理人为的与工作过程中的错误？你对其过程中的每一步都进行检查了吗？是否让别人按你的方式，按部就班，并拿出大量的表单来证明他们并没有在骗人？或者，你相信别人能做正确的事——能清除道路上的重重障碍，并随后能验证他们做得没错？相信他们但是要验证。

    我无私的读者，包括项目经理，可能会声称他们很信任他们的同事。真的吗？上一次出错时你是什么反应？你是很快修复病根并继续开展工作，还是马上展开一次为期几天或几星期的调查而打乱了团队的工作进展？你是事无巨细亲力亲为还是放手委托给别人？你是每个步骤都要干涉还是只对结果进行评定？信任没那么容易。幸运的是，好人有好报。

    似曾相识

    你的代码是松散的还是内聚的？是否所有的类、方法及功能都乱成一团麻，还是它们可以分开进行独立测试，每个代码段可以执行各自的目的及任务吗？

    有良好架构及分层的代码是易于测试、维护及改进的。但，它不如紧耦合代码的效率高。要有权衡。如果你纯粹为速度而优化，最终你得到的是一团难以维护的面条代码。如果你只为清晰的架构而优化，你就在执行效率上缺乏竞争力。你怎么把握个中尺度？

    大部分团队并没有把握好架构与效率之间的尺度——他们在玩过山车：

    1团队采用了一个非常好的架构。运行良好，每个人感觉都很好。

    2他们对它进行了性能优化。现在效率更高了——原来的团队确实不够专业。

    3代码变得难以管理，难以改进，性能遇到了瓶颈，所以这个团队只好痛苦地重构代码。然后代码又变得易于管理了，每个人都笑逐颜开——之前的团队确实还太嫩。

    4性能还不够强，所以这个团队又进行性能优化。现在性能又加强了——之前的团队确实没找对路子。

    5现在，代码又难以维护了，又要跑回到第3个步骤。

    还有一种情况——代码混乱不堪，甚至不能再重构。他们的产品周期变得越来越长，代码运行变得越来越慢，需要更多的内存及更快的CPU。这样的事常发生。

    正确的做法是优化以得到期望的结果——易于维护及改进的高性能代码。不是度量运行的速度（这很简单），而是同时度量运行速度及代码复杂度。这样你就找到了二者之间最适当的均衡度。如果你确实够精到的话，你还会度量团队健康及用户满意度指标，在这四者间找到均衡。呵呵，这就像在做买卖（讨价还价）。