第2章 重构的原则

• Refactoring 目录

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

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

重构是为了让代码“更容易理解，更易于修改”。在性能优化时，我们只关心让程序运行得更快。

添加新功能时，我不应该修改既有代码，只管添加新功能。通过添加测试并让测试正常运行，可据此衡量工作进度。

重构时就不能再添加新功能，只管调整代码的结构。此时不应该添加任何测试，除非发现之前有遗漏的测试。

一次只做一件事情，添加新功能、或者重构。

为何重构：

1. 重构改建软件的设计

   代码结构的流失是有累积效应的
   消除重复的代码，代码越多修改就越困难

2. 重构使软件更容易理解

3. 重构帮助找到Bug

   我不是一个特别好的程序员，我只是一个有着一些特别好的习惯的还不错的程序员

4. 重构提高编程速度

   越到后期效果就越明显
   “设计耐久性”

何时重构：

1. 预备性重构：让添加新功能更容易

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

2. 帮助理解的重构：使代码更易懂

   重构会引领我们获得更高层面的理解

3. 捡垃圾式重构

   如果发现的垃圾很容易重构，马上重构它； 如果需要花一些精力，先记下来，完成当下的任务再回来重构它

4. 有计划的重构和见机行事的重构

   重构不是与编程割裂的行为，不会专门安排时间重构

5. 长期重构

   请确保小步的重构不会破坏代码

6. Code review时重构

   结对编程：在编程中持续不断地进行代码复审

何时不应该重构：

1. 丑陋的代码能被隐藏在一个API之下
2. 重写比重构容易时

重构的挑战：

1. 延缓新功能开发
2. 代码所有权的边界会妨碍重构
3. 分支合并可能会让重构有冲突，建议频繁的CI集成
4. 重构需要有测试覆盖，保证能快速发现问题
5. 遗留系统的重构需要循序渐进
6. 数据库的重构最好借助数据迁移脚本，将数据库结构的修改与代码相结合

通过重构我们能得到一个设计良好的架构，使其能够优雅地应对不断变化的需求。

演进式架构，简单设计、增量式设计、或者YAGNI(You aren’t going to need it)。

要真正以敏捷的方式运作项目，团队成员必须在重构上有能力、有热情，他们采取的开发过程必须与常规的、持续的重构相匹配。

重构的第一块基石是自测试代码，一套频繁执行的CI。

自测试代码 + 持续集成 + 重构。

重构与性能：

先写出可调优的软件，然后调优它以求获得足够的速度。

不要臆测系统的性能，请实际度量它。80%的性能优化只出现在20%的代码上。

重构对于提高生产力非常重要。