关于代码重构的思考

最近翻阅了《重构 改善既有代码的设计》，对于代码重构进行了思考，也上知乎搜了相关的内容，有两个内容我个人觉得写得很好。

https://www.zhihu.com/question/19552812/answer/12206760

「重构」并不是完全打翻重来，最开始的设计也并非一无是处。软件开发是一个过程，软件使用的人群、环境都可能在进行中发生变化，当初设计中的一些假设、条件都会变化，这就需要根据新的状况做出调整。
「重构」是代码层面的「重设计」，代码是软件的实现方式，设计做出调整，代码当然也要调整。
「重构」也是对原有代码的完善，消除代码中的腐臭味，让代码更健壮、效率更高、更易维护。这是软件开发的规律决定的，没有人能一次写出完善的代码。

https://www.zhihu.com/question/19574943/answer/167272318

那怎样才算是一次合格的重构呢？我觉得至少需要做到以下几点：
消除味道：一个重构应该是从识别一个坏味道（Bad Smell）开始，以消除一个坏味道结束，任何不以消除坏味道为目标的重构都是耍流氓。
始终工作：即重构定义中的“在不改变软件可观察行为的前提下”，说白了就是重构过程不能破坏甚至改变软件外在功能。持续集成：不需要为重构单建分支，重构过程可以做到Feature开发在同一分支上持续集成持续交付。
随时中止：例如一个方法重命名，需要修改100个调用点，当改到50个的时候有个紧急的Feature，我可以随时暂停重构，立即切换到Feature开发上，且不需要回滚已做的重构。
断点续传：还是上边的例子，假如我已经完成了紧急Feature的开发，可以随时继续之前的重构，完成剩下50个调用点的重命名。
过程可逆：对于重构，经常有人会问：你怎么保证重构就会更好而不是更坏呢？重构的伟大就在于他跳出了对错之争，将关注点放到如何快速平滑安全的变化上，当然也包括反向重构。
所以我的回答是：无法保证，但是我可以一分钟就重构回来。如果仔细看，《重构》书里的所有重构手法都是双向的，比如“Extract Method”和“Inline Method”。
总结为：旧的不变，新的创建，一步切换，旧的再见。

我个人的理解是，
重构的代价是巨大的。
以前的项目都是瀑布式开发，一次重构很可能需要整个项目推倒重做。现在一般都是追求分布式、微服务、轻量级，系统讲究拆分、小而精。所以，相比于以前，现在的软件重构代码相对较小。
但是，对于业务繁重的互联网公司开发团队，首先你要兼顾现有业务的开发，而且需要同时进行新代码的创建，如果在开发资源不变的情况下，相当于每个开发人员的工作量翻倍，而且很容易造成顾此失彼的情况，更甚的是，一个业务，你在新代码重构好了，还没有投入使用，此时，策划一个新需求——业务变更，这将直接导致重构的代码又要再重构一次。
所以，重构的代价是巨大的，每一次重构都要谨慎考虑。
重构是无时无刻的。
每一次修改一个接口，每一次修改一个逻辑，都应该把它看成是一次重构。开发人员应该注重提升自己的业务水平，在平时写代码时，要尽量把代码写好。就像当代大学生一样，与其等到期末在通宵重头开始预习复习，还不如平时把该上的课上了，把改写的作业写了，出来混总是要还的。
重构应该是旧代码与新代码并行。
即上面提到的旧的不变，新的创建，一步切换，旧的再见。重构应该当做是一项日常需求来进行，一方面降低了开发人员的压力，另一方面把重构当做日常需求，这样就可以持续集成、持续测试、持续替换旧代码。

相关资料收集：
http://blog.csdn.net/pangpang123654/article/details/79269336