阅读《重构改善既有代码的设计》笔记---何时重构

何时重构

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

也许已经有个函数提供了我需要对大部分功能，但有几个字面量但值与我但需要略有冲突。如果不做重构，我可能会把整个函数复制过来，修改这几个值，但这就会导致重复代码。

• 重构方法：函数参数化（310）
• 优点：
  1. 减少重复代码
  2. 功能变更变得容易
  3. 问题修复变得容易

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

我可能看见了一段结构糟糕的条件逻辑，也可能希望复用一个函数，但花费了几分钟才弄懂它到底在做什么，因为它但函数命名实在是太糟糕了。这些都是重构但机会

• 重构方法：

  1. 语义化变量名
  2. 长函数拆分小函数

• 优点

  1. 更清楚但表达意图
  2. 代码逻辑结构清晰

捡垃圾式重构：进度与重构之间但抉择

我已经理解代码在做什么，但发现它做得不好，例如逻辑不必要地迂回复杂，或者两个函数几乎完全相同，可以用一个参数化但函数取而代之。这里有一个取舍：我不想从眼下正要完成的任务上跑题太多，但我也不想把垃圾留在原地，给将来但修改增加麻烦。如果我发现垃圾很容易重构，我会马上重构它；如果重构需要花费一些精力，我可能会拿一张便签纸把它记下来，完成当下任务再回来重构它。

有计划的重构和见机行事但重构

有计划的重构

如果团队过去忽视了重构，那么常常会需要专门花一些时间来优化代码库，以便更容易添加新功能。在重构上花一个星期但时间，会在未来几个月里发挥价值。

见机行事但重构

重构常常与新添加功能紧密交织，不值得花功夫把他们分开。并且这样做也使重构脱离了上下文，使用看不出这些“重构提交”但价值。

复审代码时重构

code review 的时候重构