代码重构梳理-前言

　　对既有的代码是隐忍还是重构，对于初次尝试重构的开发人员来说总要经历一段很长时间的纠结。走出重构的第一步对每一个人来说都是一次心灵的考验，甚至有许多人总是徘徊于路口踌躇不前，但一旦跨出去了，它将成为你生命的一部分。

一：修改软件的四种动机：
1、增加新功能；
2、原有功能有BUG；
3、改善原有程序的结构；
4、优化原有系统的性能。
　　前两种源于客户的功能需求，第四种源于客户的非功能需求。而要提高软件的内部质量，我们就需要改善原有程序的结构。

二：如何提高软件的内部质量
1、程序易于阅读，可读性要强；
2、“抽取方法”分解难于阅读与维护的大函数，“抽取对象”分解无所不能的大对象。
3、使我们的软件易于维护，易于变更。

三：重构是一种习惯
　　重构走下了神坛，不再是系统架构师或者软件大牛的专利，它应当是屌丝们的最爱，成为普通程序员与初学者走向优秀程序员的捷径。当你具备了以下这些意识，你就具备了一个优秀程序员的素质。
当添加新功能而发现既有代码凌乱而难懂时，先重构改善既有代码；
当开发新功能而发现既有代码可以复用时，先重构再复用；
当增加新需求而发现既有代码不适应该需求时，先重构以适应新需求；
当新功能需要既有功能能够扩展而既有代码不能够时，先重构把扩展点做出来再说。

四：重构让程序可读
　　它将给我们一个最佳的投资回报。

五：重构才好复用
　　没有经过重构的、原生态的代码是没法复用的，当发现代码需要复用时，切忌不要简单粗暴的使用复制粘贴。

六：先重构，再扩展
　　要保证每次需求的变更时软件质量不会下降，必须记住这样一个原则:先重构再添加新功能。
　　添加新功能前先重构原有系统，其目的有两个：
　　1、软件的设计总是与软件的复杂程度有关的，原有的设计是在原有需求不复杂的条件下做出的，但随着新功能的加入，软件复杂度在发生着变化，因此必须要调整原有的设计以适应新的需求；
　　2、为了提高软件的可维护性与易变更性，添加新功能应遵循OCP原则。而要遵循OCP原则，我们应当在不添加新功能的前提下先进行重构，设计出可扩展点出来，然后再添加新功能。

七：变更任务紧急时，该如何重构
　　在不紧急的情况下我们的重构往往会彻底一些、完备一些，而在紧急任务中的重构则更加务实一些。重构既有的代码更加少一些，范围小一些，使得重构能刚刚满足需要就可以了。另外一种更加务实的办法就是，你可以进行比较完备的设计，但只做此次任务所需的开发，将剩余的工作预留出来等此次任务完成以后再进行。–做完整的重构设计，但只做重构中最紧急的那部分。

大胆地、适时地进行重构，才能真正使我们的软件系统始终保持一种高质量。