《重构：改善既有代码的设计(第2版)》 ePUBw.COM 61个笔记
◆ 第2章 重构的原则
把自己的时间分配给两种截然不同的行为：
添加新功能和重构
重构改进软件的设计
代码结构的流失有累积效应。越难看出代码所代表的设计意图，就越难保护其设计
于是设计就腐败得越快。
改进设计的一个重要方向就是消除重复代码。
消除重复代码
重构使软件更容易理解
重构帮助找到bug
重构能够帮助我更有效地写出健壮的代码
重构提高编程速度
何时重构
三次法则
第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构。
重构的最佳时机就在添加新功能之前。
帮助理解的重构：使代码更易懂
先在一些小细节上使用重构来帮助理解，给一两个变量改名，让它们更清楚地表达意图
将一个长函数拆成几个小函数。当代码变得更清晰一些
捡垃圾式重构
我已经理解代码在做什么，但发现它做得不好
如果我发现的垃圾很容易重构，我会马上重构它；如果重构需要花一些精力，我可能会拿一张便笺纸把它记下来
如果每次经过这段代码时都把它变好一点点，积少成多，垃圾总会被处理干净
重构不是与编程割裂的行为
肮脏的代码必须重构，但漂亮的代码也需要很多重构。
2023/7/20 发表想法 指分开重构 & 添加新功能
重构常常与新添功能紧密交织，不值得花工夫把它们分开。
重构常常与新添功能紧密交织，不值得花工夫把它们分开。
如果想替换掉一个正在使用的库，可以先引入一层新的抽象，使其兼容新旧两个库的接口。
这个策略叫作Branch By Abstraction
在编程的过程中持续不断地进行代码复审。
只有当我需要理解其工作原理时，对其进行重构才有价值。
如果重写比重构还容易，就别重构了
如果一块代码我很少触碰，它不会经常给我带来麻烦，那么我就倾向于不去重构它。
我们之所以重构，因为它能让我们更快
推荐团队代码所有制
对于开源项目，特性分支可能是合适的做法，因为不时会有你不熟悉（因此也不信任）的程序员偶尔提交修改。
全职的开发团队而言，特性分支对重构的阻碍太严重了。即便你没有完全采用CI，我也一定会催促你尽可能频繁地集成。
自测试的代码不仅使重构成为可能，而且使添加新功能更加安全
修改代码的艺术
先找到程序的接缝，在接缝处插入测试，如此将系统置于测试覆盖之下
从一开始就写能自测试的代码
数据库重构最好是分散到多次生产发布来完成
新添一个字段
同时写入新旧两个字段
暂停
是否有bug
再删除已经没人使用的旧字段
Parallel Change
应对未来变化的办法之一，就是在软件里植入灵活性机制
只根据当前的需求来构造软件
把软件的设计质量做得很高
只有当未来重构会很困难时，我才考虑现在就添加灵活性机制
简单设计、增量式设计或者YAGNI
you arenʼt going to need it
自测试代码、持续集成、重构
比起一个塞满了想当然的灵活性的系统，当然是修改一个简单的系统要容易得多
合适的平衡点
哪怕你完全了解系统，也请实际度量它的性能，不要臆测
度量工具
哪些地方大量消耗时间和空间
找出性能热点
短期看来，重构的确可能使软件变慢，但它使优化阶段的软件性能调优更容易，最终还是会得到好的效果。
