重构摘要2_重构原则

创建于：2014-03-30 | 分类： java重构  | 标签： 重构 

何谓重构

对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提交其可理解性，降低其修改成本。

  • 重构的目的是软件更容易理解和修改；
  • 重构不会改变软件可观察的行为。

两顶帽子比喻

  • 添加新功能 不修改既有代码，只管添加新功能，并通过测试
  • 重构 不添加功能，只管改进程序结构


为何重构

重构改进软件设计

  • 改进的重要方向就是消除重复代码。

重构使软件更容易理解

  • 准确说出我所要的

  • 利用重构来协助我理解不熟悉的代码

  • 随着代码渐趋简洁，发现可以看到一些以前看不到的设计层面的东西。

重构帮助找到BUG

我不是个伟大的程序员，只是个有着一些优秀习惯的好程序员。

重构提高编程速度


何时重构

几乎任何情况下都反对专门拨出时间重构。重构应该随时随地。不应该为重构而重构，你之所以重构，是因为你想做别的什么事，而重构可以帮助你把那些事做好。

三次法则

事不过三，三则重构

添加功能时重构

最常见的重构时机就是我想给软件添加新特性的时候。

  • 往往是为了帮助我理解需要修改的代码。

  • 代码结构清晰，我就可以从中理解更多的东西。

  • 代码的设计无法帮助我轻松添加我所需要的特性。

  • 重构是一个快速流畅的过程

修补错误时重构

调试过程中运用重构，多半是为了代码更具可读性。

复审代码时重构

重构可以帮组我复审别人的代码。

程序难以相与的原因：

  • 难以阅读的程序，难以修改；
  • 逻辑重复的程序，难以修改；
  • 添加新行为时需要修改已有代码的程序，难以修改；
  • 带复杂条件逻辑的程序，难以修改。

希望的程序：

  • 容易阅读；
  • 所有逻辑都只在唯一地点指定；
  • 新的改动不会危及现有行为；
  • 尽可能简单表达条件逻辑。

技术复审是减少错误，提高开发速度的一条重要途径。

“计算机科学是一门科学：它相信所有问题都可以通过增加一个间接层来解决。 Dennis DeBruler”

但是它是一把双刃剑。

间接层的某些价值：

  • 允许逻辑共享。 比如说一个子函数在两个不同的地点被调用，或超类中的某个函数被所有子类共享。
  • 分开解释意图和实现。 你可以选择每个类和函数的名字，这给了你一个解释自己意图的机会。类或者函数内部则解释实现这个意图的做法。如果类和函数内部又以更小单元的意图来编写，你所写的代码就可以描述其结构中的大部分重要信息。
  • 隔离变化。 很可能我在两个不同的地点使用同一个对象，其中一个地点我想改变对象行为，但如果修改了它，我就要冒同时修改两处的风险。为此，我做出一个子类，并在需要修改处引用这个子类。现在，我可以修改这个子类而不必承担无意中影响另一处的风险。
  • 封装条件逻辑。 对象有一种奇妙的机制：多态消息，可以灵活而清晰地表达条件逻辑。将条件逻辑转化为消息形式，往往能降低代码的重复、增加清晰度并提高弹性。

找到不值得的间接层，并将它拿掉。（最终只一处用）


重构的难题

数据库

修改接口

让旧接口继续工作。请尽量这么做：让旧接口调用新接口。当你要修改某个函数名称时，请留下旧函数，让它调用新函数。Java中有deprecation不建议使用。

不要过早发布接口，请修改你的代码所有权政策，使重构更畅顺。

Java还有一种特别的接口修改：在throws子句中增加一个异常。通常，我总喜欢为整个包（package）定义一个异类基（就像java.sql的SQLEception）。

最开始设计要花多少时间

先想象设计重构为另一个设计的难度有多大？如果看上去简单，那么就不必太担心选择是否得当，于是我就会选最简单的设计，哪怕它不能覆盖所有潜在的需求也没关系。但如果预先看不到简单的重构办法，我就会在设计投入更多力气。不过我发现，后一种情况很少出现。

何时不该重构

重构它还不如重新写一个来得简单。

重构之前，代码必须起码能够在大部分情况下正常运作。

将“大块头软件”重构为封装良好的小型组件。

如果项目已近最后期限，你也应该避免重构。

比喻：重构工作是“债务”，公司可以借债，但不要过重。

多个项目经验显示：重构的确能够提高生产力。如果你最后没有足够时间，通常表示你其实早该进行重构。


重构与设计

如果问“把一个简单的解决方案重构成一个灵活的方法有多大难度？” 如果答案是“相当容易”（大多数时候都如此），那么你就可以只需实现目前的简单方案就行了。

哪怕你完全了解系统，也请实际度量它的性能，不要臆测。


重构与性能

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

三种编写快速软件的方法

  • 最严的是时间预算法

  • 持续关注法 事与愿违，因为性能改善一旦分散到程序各角落，每次改善都只不过是从对程序行为的一个狭隘视角出发而已。

通常，大半时间都耗费在一小半代码身上。

  • 统计数据，直至进入性能优化阶段（后期），再按照某个特定程序来调整程序性能。

需要一个度量工具，找出大量消耗时间和空间的性能热点。小幅度改进，测试，度量。

良好构造的程序可以优化这一过程。

有比较充裕的时间调整性能，可以更快添加功能。

可以在性能分析时便有较细的粒度。更好的理解选择，更清楚哪种调整起关键作用。


本节，我们把重构看做整个软件开发过程的一个关键环节。

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

说明