重构笔记2

重构的挑战

延缓新功能开发

实际上，这只是一部分不理解重构真正原因的人的想法，重构是为了从长效上见到收益，一段优秀的代码能让我们开发起来更顺手，要权衡好重构与新功能的时机，比如一段很少使用的代码。就没必要对他重构

代码所有权

有时候我们经常会遇到，接口发布者与调用者不是同一个人，并且甚至可能是用户与我们团队的区别，在这种情况下，需要使用函数改名手法，重构新函数，并且保留旧的对外接口来调用新函数，并且标记为不推荐使用。

分支的差异

经常会有长期不合并的分支，一旦存在时间过长，合并的可能性就越低，尤其是在重构时候，我们经常要对一些东西进行改名和变化，所以最好还是尽可能短的进行合并，这就要求我们尽可能的将功能颗粒化，如果遇到还没开发完成且又无法细化的功能，我们可以使用特性开关对其隐藏

缺乏一组自测试的代码

一组好的测试代码对重构很有意义，它能让我们快速发现错误，虽然实现比较复杂，但他很有意义

遗留代码

不可避免，一组别人的代码使得我们很烦恼，如果是一套没有合理测试的代码则使得我们更加苦恼。这种情况下，我们需要增加测试，可以运用重构手法找到程序的接缝，再接缝处增加测试，虽然这可能有风险，但这是前进所必须要冒的风险，同时不建议一鼓作气的把整个都改完，更倾向于能够逐步地推进

 

何时不应该重构

不需要修改的代码

隐藏在一个API之下，只有当我需要理解其工作原理时，对其进行重构才有价值

重写比重构还容易

重构与其他的关系

开发：短期会耽误一定的开发事件，但从长期来看，重构使得新功能会更容易开发

性能：会影响部分性能，但在大多数的加持下，显得微不足道，并且重构有利于性能优化的点集中于某一处或者几处

架构：相辅相成

需求：需求推动重构前进