你好，我是小树。这是我为你写的第 89 封信。每期都会同步更新在微信公众号一颗小树。
最近接触到一部分新业务，在开发过程中经常会做一些旧有逻辑的梳理和重构，又翻开《重构：改善既有代码的设计》这本书重读了一遍。
有一些观点值得学习：
如果你要给程序添加一个特性，但发现代码因缺乏良好的结构而不易于进行更改，那就先重构那个程序，使其比较容易添加该特性，然后再添加该特性。
很多代码并不是一开始就变差的，大多是因为实现短期目标而忽视了整体的架构设计和原则，于是代码就慢慢失去了自己的结构。
接手者越来越难通过直接阅读源码来理解原有的设计，想要做优化又担心影响已有的功能，于是问题逐渐累积，最终积重难返。
重构的一个很好的时机就是在添加新功能之前。
尤其是在不够熟悉的业务面前，我需要先理解代码在做什么，然后才能着手修改，重构也是理解代码的最快方式。
在重构前，先实现完备的测试，以便在重构过程中持续检验是否破坏了原有的代码逻辑。
重构中出问题是不可避免的，完备的测试是非常必要的。
通常情况下，不建议在重构过程中加入其他的新功能和 bug 修复，重构应当是在已有逻辑不变的情况下，让后续的改动更容易。
因此，事前梳理好用户视角的功能测试用例，或是偏向代码本身的 E2E 测试和单元测试，都能很好地保障已有逻辑。
小步修改，频繁反馈，避免改动太多导致排查问题困难。重构的关键在于运用大量微小且保持软件行为的步骤，一步步达成大规模的修改，尽可能避免让代码进入不可工作的状态，即使重构没有完成，也可以随时停下来。
重构过程中，尽量避免一步到位的想法。把重构的粒度拆的足够细，让每次提交都能独立工作，并且通过测试用例。
这样的好处是能够及时发现自己改动的错误，很容易定位和修复，如果一次性改动过多，遇到问题很可能就前功尽弃了。
好代码的检验标准是人们能否轻而易举地修改它。
这个应该不用解释，遇到过一次很难改的代码就懂了。
重构和性能优化是两回事，重构是为了让代码更容易修改，性能可能变快也可能变慢，性能优化更关心如何变得更快，代码可能会变得更难理解和维护。
关于性能，其实在开始的时候就建立比较完备的度量是很重要的，这样才能发现真正的性能瓶颈。
如果一上来就使用常规的方式去做优化，很可能大部分优化工作都是不必要的，有可能被优化的代码很少执行，或者是影响甚微。
性能问题往往都处在细微之处。
最后，用书中的一句话结尾吧。
重构的意义不在于把代码库打磨得闪闪发光，而是因为它能让我们更快：添加功能更快，修复 bug 更快。
碎碎念
最近发现上海译文出版社再版了村上春树的一套书，想起了 10 年前在学校图书馆看的白色封面的那一套。
找点时间，再看一遍吧。
谢谢你的关注，我们下期再见。👋🏻
往期推荐
你也可以在这里找到我：即刻、Twitter、微信公众号一颗小树。
如果你觉得这篇文章对你有用，欢迎分享给更多好友。