Chapter 2 ：重构的原则

1，什么是重构？

在不改变软件可观察行为的前提下，使用一些重构的手法，提高代码可读性。

换句话说，在保持软件可用的前提下，修改代码使得更加容易被理解。

2，为什么重构？

为了后续的代码维护和修改，易读是重构的核心价值。

除此之外，重构随之带来的好处有：

• 找到bug
• 提高编程速度（在代码量累计到一定程度时，重构过的代码会更加易于添加新功能）

3，什么时候重构？

• 添加新功能之前重构 添加新功能最快的方法往往是先修改现有代码，使新功能容易被加入。
• 使代码更易理解时重构
• 顺便重构（修复bug，添加新功能）
• 代码复审（code review）时重构

总而言之：重构的门槛远远没有想象中那么高，重构是对既有代码的修改，也许我们在无意识中就已经做了这样的工作，一方面继续保持良好的编程习惯，另一方面学习更加成体系的重构手法。

就如同重构的定义，在可用的前提下，提高重构的技术。

什么时候不应该重构？

对于一段凌乱的代码，如果不需要修改它，就不需要重构。

只有当你需要理解其工作原理时，重构才变得有价值。

如果重写比重构更加容易，那就不需要重构了。（判断）

4，重构会遇到哪些问题？

“毕竟生活里很少有晴空万里的好事”

——Martin Fowler

延缓新功能开发

先添加新功能再重构，还是先重构再添加新功能，这不是一个对错的问题，而是一个取舍的分叉口。

Martin Fowler的回答醍醐灌顶，作为程序员往往对代码库的整洁有着极高的追求，以技术去驱动重构没有错，但现实世界往往取决于经济。

“重构的意义不在于把代码库打磨的闪闪发光，而是纯粹经济角度出发的考量。”

“重构应该总是由经济利益驱动。”

除了重构之外，现在的团队开发，前后端分离等等，不仅是技术发展的必然结果，同时也是经济化必然的结果。同样的场景，是否重构更多取决于经济条件。

代码所有权成为重构阻力

修改函数声明和调用可能也会遭遇声明者无法修改调用者代码的权限问题。

Martin Fowler推荐的是团队代码所有制。对于跨团队的兼容，可以采用类似GitHub上开源的模型。

(在强代码所有制和混乱修改的折中)

分支合并问题

在隔离的分支上工作的越久，需要完成的集成工作就越困难。

持续集成（CI：Continuous Integration）：也称基于主干开发。为了避免彼此分支差异过大，每个团队成员每天至少向主线集成一次。

使用CI的代价：必须使用相关的实践保持主线的健康状态。

快速的自测试

建立一套完备的测试套件，并且需要快速运行。

准备这套测试套件的代价很高，但收益也是可观的：

• 使重构可行性变得更大
• 使添加新功能更加安全
• bug排查更加迅速，容易

遗留代码

重构可以很好的理解遗留系统，但同时又是十分危险的。

再次推书了，hhh《修改代码的艺术》：运用重构手法创造出接缝，在接缝处插入测试。（当然，具有一定风险）

数据库

flower先生的同事发明了一套渐进式数据库设计和数据库重构的方法.......

（看书就好像布置家庭作业一样。。。难顶）

5，重构与性能优化

重构：使代码更易读

性能优化：使代码运行速度更快

先写出可调优的软件（重构），然后对其调优达到足够的速度（性能优化）。

关于性能优化：现状——大半时间都花在了一小段代码上。

使用一个度量工具监控程序的运行，找出性能热点的一小段代码集中调优。

6，自动化重构

Intellij IDEA可以自动重构的......（说明我对这个工具的利用程度还不够高）