【软件设计】重构

什么是重构

改善既有代码的设计。
对软件内部结构的一种调整， 目的是在不改变软件可观察行为的前提下，提高其理解性，降低其修改成本。
重构不止是代码优化，重构更注重提高代码的可理解性与扩展性。

为什么要重构

1、改进软件的设计
如果没有重构， 在软件不停的版本迭代中， 代码的设计只会越来越腐败，导致软件开发寸步难行。
人们只为了短期目的而修改代码时，往往没有完全理解整体的架构设计， 代码就会失去自己的结构，代码结构的流失具有累积效应，越难看出代码所代表的设计意图，就越难保护其设计。
我们几乎不可能预先做出完美的设计，以面对后续未知的功能开发，只有在实践中才能找到真理。

2、使得代码更容易理解
在开发中， 我们需要先理解代码在做什么，才能着手修改，很多时候自己写的代码都会忘记其实现，更不用论别人的代码。可能在这段代码中有一段糟糕的条件判断逻辑，又或者其变量命名实在糟糕又确实注释，需要花上好一段时间才能明白其真正用意。
合理的重构能让代码“自解释” ，以方便理解，无论对于协同开发，还是维护先前自己实现的功能，对代码的开发有着立竿见影的效果。

3、提高开发是速度
提高开发的速度可能有点“反直觉”，因为重构在很多时候看来是额外的工作量，并没有新的功能和特性产出，但是减少代码的书写量（复用模块），方便定位错误（代码结构优良），这些能让我们在开发的时候节省大量的时间，在后续的开发中“轻装上阵”。

重构的时机

1、添加新功能之前
在动手添加新功能之前，看看现有的代码库，此时经常会发现，如果对代码结构做一点微调，自己的工作会轻松很多。比如有个函数提供了需要的大部分功能，但有几个字面量的值与自己的需求不同。如果不做重构，需要复制整个函数再进行微调，这导致重复代码的产生，这是代码臭味道的开始。所以需要戴上重构的“帽子”，做完这件事后，再轻松的开发你的功能。

2、完成新功能之后
结合任务的排期和实际的工作，重构的最佳时机是在完成一个功能后和 code review 后。
在每完成一个功能后重构，也类似于垃圾回收中的时间分片的思想，不必等到代码中塞满“垃圾”时才开始清理，导致“全停顿”的发生。将重构分解为一小步一小步。对代码更清晰，能让我们更好的定位问题和提高自己的代码水平。

3、难以添加新功能时
其实并不希望这个状况发生，这代表代码结构已经处于混乱中，添加新功能需要翻越好几个障碍。此时重构是个必选项，也必然是个大工程，这会造成项目的“全停顿”。更糟糕的是此时重构可能不如直接重写，这是我们需要避免的情况。

什么时候不该重构

1、重写比重构容易

2、不需要理解该片段时

3、未与合作者商量时

重构与性能

代码重构和性能优化是两个不同的概念， 重构仅仅只考虑代码的可理解性和可扩展性， 对于代码的执行效率是不看重的。而重构对于性能的影响，也很可能没有你想象中的那么高，在面对大部分的业务情况时，重构前和重构后代码的性能差别几乎难以体现。
大部分情况下，我们不需要极致的“压榨”计算机，来减少使用的微乎其微的计算机时钟周期时间，更重要的是，减少自己在开发中使用的时间。