重构第二章读书笔记

何为重构

重构（名词）：

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

动词形式的定义是：
重构（动词）：使用一系列重构手法，在不改变软件可
观察行为的前提下，调整其结构。

重构的关键在于运用大量微小且保持软件行为的步骤，一步步达成大规模的修改。

• 重构与结构调整的区别

结构调整泛指对代码库进行的各种形式的修改与清理。重构则是一种特殊类型的结构调整，为了自己的相关的目的。

• 重构与性能优化的区别

相同点
重构和性能优化都需要修改代码，并且两者都不会改变程序的整体功能。

不同点
重构是为了让程序 更容易理解，更容易修改。这可能让程序运行的更快，也可能更慢。 而性能优化，则更倾向于程序的运行性能，对于可维护性，不会特别关注。

为何重构

• 重构可以让代码更易读。

重构可以帮我让代码更易读。开始
进行重构前，代码可以正常运行，但结构不够理想。在重构
上花一点点时间，就可以让代码更好地表达自己的意图——
更清晰地说出我想要做的

• 重构帮助找到bug
• 重构提高编程速度

何时重构

三次法则
第一次做某件事时，只管去做；第二次去做时，就会反感，但是还是要去做；第三次，则需要重构了。 事不过三，当重复被某件事影响时，就去解决它。

• 预备性重构

重构的最佳时机就是在添加新功能之前。

• 帮助理解的重构

我需要先理解代码在做什么，然后才能着手修改。这段
代码可能是我写的，也可能是别人写的

• 捡垃圾式重构

野营法则：至少要让营地比你到达时更干净。

• 有计划的重构和见机行事的重构

肮脏的代码必须重构，但漂亮的代码也需要很多重构。

每次要修改时，首先令修改很容易（警告：这件事有时会很难），然后再进行这次容易的修改。

• 长期重构

抽象分支策略
如果想替换掉一个正在使用的库，可以先引入一层新的抽象，使其兼容新旧两个库的接口。一旦调用方已经完全改为使用这层抽象，替换下面的库就会容易得多

• 复审代码时重构

重构的挑战

延缓新功能开发

很多重构手法不仅会影响一个模块内部，还会影响该模块与系统其他部分的关系

代码所有权

分支

• 主分支发布-特性分支开发管理策略

很多团队采用这样的版本控制实践：每个团队成员各自在代码库的一条分支上工作，进行相当大量的开发之后，才把各自的修改合并回主线分支（这条分支通常叫master或trunk），从而与整个团队分享。常见的做法是在分支上开发完整的功能，直到能可以发布到生产环境，才把该分支合并回主线。这种做法的拥趸声称，这样能保持未完成的代码侵扰，能保留清晰的功能添加的版本记录，并且在某个功能出问题时能容易地撤销修改。

缺点：在隔离的分支上工作得越久，将完成的工作集成（integrate）回主线就越困难。为了减轻集成的痛苦，大多数人的办法是频繁地从主线合并（merge）或者变基（rebase）到分支。

• 持续集成

分支合并本来就是一个复杂的问题，随着特性分支存在的时间加长，合并的难度会指数上升。集成一个已经存在了4个星期的分支，较之集成存在了2个星期的分支，难度可不止翻倍。所以很多人认为，应该尽量缩短特性分支的生存周期，比如只有一两天。还有一些人（比如我本人）认为特性分支的生命还应该更短，我们采用的方法叫作持续集成（Continuous Integration，CI），也叫“基于主干开发”（Trunk-Based Development）

测试

自测试代码的优势
自测试的代码不仅使重构成为可能，而且使添加新功能更加安全，因为我可以很快发现并干掉新近引入的bug。这里的关键在于，一旦测试失败，我只需要查看上次测试成功运行之后修改的这部分代码；如果测试运行得很频繁，这个查看的范围就只有几行代码。知道必定是这几行代码造成bug的话，排查起来会容易得多。

重构与软件开发过程

敏捷开发三要素

• 自测试代码
• 持续集成
• 重构