改善既有代码的设计（二）----------重构和性能

  上一篇文章用一个小例子展示课一下重构的魅力，作者写书是要顾全到各种语言，各种项目，所以大家不论是做Android还是ios还是后台的，还是前端的，都不要用太较真的眼光来看这本书，要想顾全大局，难免会宽泛了许多，我们只要领会他的精神，了解他的手法，然后自己运用到自己所涉猎的行业即可。

  一旦牵扯重构，有一个问题会被经常提出，那就是他对程序的性能会造成怎么样的影响，

  对于这个问题也是我比较好奇的，因为这篇的介绍没有代码，可能大家兴趣会大大降低，所以为了，引诱大家来读，我可能会让一些稍微不正式的语言穿插其间，这些语言不代表我的个人素质，希望大家谅解。

  小搬运工开工啦：

  为了让软件易于理解，你经常会做出一些让程序变慢的修改，这是个重要的问题，我并不赞成为了提高设计的纯洁性而忽视性能，把希望寄托于更快的硬件身上也绝非正道，已经存在很多软件就是因为太慢而被用户拒绝，日益提高的机器速度也不过是略微的放宽了速度方面的限制而已，但是，换个角度来说，重构能虽然可能使软件运行更慢，但是他也使软件的性能优化更容易。

（个人觉得这句话才是精髓，眼光放长远点，不要做了一步操作就立马去对这个做法评头论足，前期的重构是为了占领最高阵地，等到优化这一战役打响的时候，我们有更高的优势，了然？）

  除了对性能有严格的要求的实时系统，其他任何情况下“编写快速的软件”的秘密就是：首先写出可调的软件，然后调整他以求获得足够的速度

  我看过三种编写快速写软件的方法，其中最严格的是时间预算发法，这通常只用于性能要求极高的实时系统，如果使用这种方法，分解你的设计时就要做好预算，给每个组件预先分配一定资源，包括时间和执行轨迹，每个组件绝对不能超出自己的预算，就算拥有组件之间调度预配时间的机制也不行，这种方法高度重视性能，在这样的系统中，迟来的数据就是错误的数据，但是对于其他系统而言，如此高追求性能就有点过分了。

 （其实读完觉得好像没读一样吧，我也是，但是我么可以领略作者的意思，因为我们也没有涉及到这么严谨的实时系统，对他的一番描述也没有实质性的理解，so,这一段可以忽略）

第二种方法是持续关注，这种方法要求程序员在任何时间做任何事情时，都要设法保持系统的高性能，这种方式很常见，感觉上很有吸引力，但通常不会有太大作用，任何修改如果是为了提高性能，通常会使程序难以维护，继而减缓开发速度，如果最终得到的软件速度确实快了，那么这点损失尚有所值，可惜通常事与愿违，因为性能改善一旦被分散到程序各角落，每次改善只不过是从程序行为的一个狭隘视觉出发而已

  (这个好像还那么好懂一点)

  关于性能，一件很有趣的事情就是：如果对大多数程序进行分析，就会发现他把大半时间都耗费在一小半代码上，如果一视同仁的优化所有代码，90%的优化工作都是白费的，因为被你优化的代码大多很少被执行，你花时间做优化是为了让程序运行更快，但是如果因为缺乏对程序的清楚认识而花费时间，那这些时间就被浪费掉了

（说实话，这一段文字丝毫没有给作者进行任何的改编，因为我感觉即使我不加自己的理解也会被人拍砖，所以没敢妄加自己的理解，这种单纯文字性的解说最容易引起反驳了，毕竟没有严谨的代码有说服力，这里就各自理解各自的吧，我觉得站在长远和更高的角度上来说，这些话是见解的，天生爱吐槽的可以飘走了，忽略不看）

 第三种性能提升的方法就是利用上述的90%统计数据，采用这种方法时，你编写构造良好的程序，不对性能投以特别的关注，直至进入性能优化阶段，--那通常是开发后期，一旦进入该阶段，你再按某个特定程序来调整程序性能

在性能优化阶段，首先应该用一个度量工具来监控程序的运行，让它告诉你程序中哪些地方大量消耗时间和空间，这样就可以找出性能热点所在的一小段代码，然后集中关注这些热点

一个构造良好的程序可以从两方面帮助这一优化形式，首先，他让你有比较充足的时间进行性能调整，因为有良好构造的代码在手

，就能够更快速的添加功能，也就有更多的时间用在性能上，其次，面对良好构造的城程序，你在进行性能分析时便有较细的粒度，于是度量工具把你带入范围较小的程序段落中，而性能的调整也比较容易些，由于代码更加清晰，因此你能够更好的理解自己的选择，更清楚哪种调整起关键作用，

我发现，重构可以帮助我写出更快的软件，短期看来，重构的确可能使软件变慢，但它使优化阶段的软件性能调整更容易，最终还是会得到好的结果。

（好的，作者已经给我们解释完了之前的那些疑惑，希望大家不要咬文嚼字，这不是一个眼界长远，心胸宽阔的程序员之所为。）

虽然这篇文章好像屁都没说一点，但是本着严谨的态度，还是要在这里给一个解释。让懂的人更懂，不懂的人慢慢懂一点，虽然我也不太懂，大家懂才是真的懂