最近和一位朋友聊到软件开发中的代码重构这个话题，诸如重构原则包括时机的考虑、间接层扩展、投入产出平衡点等问题。于是本人将以前买的《重构：改善既有代码的设计》这本书又拿起来读了一遍，并对部分章节做了读书笔记。
对于这本书，可能很多人已经阅读过，总体上还是挺经典的。这里结合自己的理解，我把其中比较重要的地方做了一些提炼，主要分析梳理重构原则相关内容。
1. 重构的定义
重构是对软件内部结构的一种调整，主要是在不改变软件可观察行为的前提下，调整其结构，以提高软件代码的可理解性，并降低修改成本。
这里要注意代码重构中的两顶帽子：一是添加新功能时，不要修改已有代码；二是在重构时，只管改进程序结构，不去添加新功能。
简单来说，就是将添加新功能与代码重构这两项工作分开处理、不混在一起。因为重构的基本前提就是不影响软件的功能特性，而且分开处理，也可以降低重构难度。
2. 重构的时机
我们对软件代码进行重构，可能是为了改进软件设计，也可能是试图让代码更容易理解，或是为了帮助发现潜在bug，那么，什么时候应该考虑重构？也即重构时机问题。
作者Martin Fowler认为，应该考虑重构的时机，有三个：添加功能时、修补错误时、复审代码时。
在添加新功能时，是否需要重构，还有一个辅助的参考判断，就是改用其他设计方式，是否可以简化我们的工作，或者说，重构之后是否可以更快、更方便地添加新功能。
与之对应地，不应该重构的时机，又分别包括：现有代码根本不能正常运行时、项目进度不允许时。
因为代码重构工作一般都需要足够的时间，这里就需要我们结合当前项目状态和软件版本计划综合评估。例如在项目后期，产品即将发货时，软件版本的稳定性和发货时间更为重要。这时候就不太适合启动代码重构了。
3. 间接层
除了重构时机之外，还有一个问题也是需要关注的，就是间接层的增加与删除。
间接层也可以叫中间层或者适配层，主要是用来减少耦合、隔离变化、复用逻辑，这里还是根据使用场景，评估投入产出，预期收益大于重构的付出时，考虑引入中间层。
例如，移动终端上，我们需要让一套应用代码运行在多个平台，减少代码维护工作量。典型的场景是：不同芯片厂家或者不同的芯片系列往往分别对应一个平台。这时候可以在各个平台框架层与应用层之间增加一个间接层，来适配不同平台框架接口的差异对应用层代码的影响。
这个间接层可以考虑放在应用层里面，也可以放在平台框架层扩展，更多的时候，在应用层和平台框架层都需要扩展修改，还看这个应用所依赖的框架层接口，在不同平台间的差异有哪些。
关于代码重构，暂时先到这里，后面继续探讨，欢迎关注。
