读《重构改善既有代码的设计》（三）

何时重构

重构不是一件需要特别拨出时间来做的事情，重构应该随时随地进行。我们不应该为了重构而重构，我们之所以重构，是因为我们想做别的什么事，而重构可以帮助我们把这件事做得更好。

三次法则：第一次做某些事时只管去做；第二次做类似的事会产生反感，但无论如何还是可以去做；第三次再做类似的事，我们就应该重构了。

添加功能时重构

最常见的重构时机就是我们想给软件添加新特性的时候。重构直接的原因，往往是为了帮助我理解需要修改的代码。因为如果在前进过程中把代码结构理清，我们就可以从中理解更多东西。

另一个原动力就是：代码的设计无法帮助我轻松添加我所需要的特性。重构是一个快速流畅的过程；一旦完成重构，新特性的添加就会更快速、更流畅。

修改错误时重构

调试过程中运用重构，可以让代码更具有可读性。我们可以通过重构帮助我们加深理解。以这种方式来梳理代码，往往可以帮助我们找出bug。

审查代码时重构

代码复审可以改善开发状况，有助于在团队中传播知识。也有助于让较有检验的开发者把知识传递给欠缺经验的人。

重构可以帮助我们复审别人的代码。还可以帮助代码审查工作得到更具体的结果。

重构的难题

数据库

重构经常出问题的一个领域就是数据库。因为绝大部分的程序都和它们背后的数据库紧密耦合，这也是数据库结构难以修改的原因之一。另一个原因就是数据迁移。

在非对象数据库中，解决这个问题的办法之一就是：在对象模型和数据库模型之间插入一个分隔层，这就可以隔离两个模型各自的变化。当然我们无需在一开始就插入分隔层，可以在发现对象模型变得不稳定时再产生它。

修改接口

对于对象，另一个重要事情就是：它们允许你分开修改软件模块的实现和接口。你可以安全地修改对象内部实现而不影响他人，但对于接口要特别谨慎。