1：什么是重构？
重构是一个过程：在不改变代码外在行为的前提下，对代码做出修改，以改进程序内部结构。本质上说，重构就是【在代码写好之后改进它的设计】
2：为什么要对项目进行重构呢？重构对软件开发有什么好处，
为什么要重构呢，打个贴切的比方：我平时比较懒散，屋子里面的东西都是随手乱放，时间长了，屋子里面就乱七八糟了。有时候到了自己也忍无可忍的时候，我就要大动干戈了，把该放哪儿的东西都整理到哪儿，该扔掉的东西全部扔掉。一个项目也是如此，有时候可能是设计不到位；有时候可能是经过多人的修改，代码凌乱不堪；甚至有些地方都是在堆砌代码；可能有些新手写的代码或是自己以前写的代码，让你看不下去了…。于是你挥动大斧对项目进行劈砍一番。
重构的好处用自己的话简单的概括为: 改善软件设计、提高代码质量、提高程序可读性、减少错误、使以后功能扩展更容易。
【重构改进软件设计】
大家可能都有亲身体会，一个项目的代码质量往往有可能会随着时间的推移变得越来糟糕，代码愈来愈雍窘，越来越难以理解它的本意。添加新功能越来越难。这里面的原因是多方面的，重构可以减少代码量，使以后的维护，开发更方便
【重构使软件更容易理解】
重构整理过后的代码，确实让你更容易理解
【重构有助于你找到BUG】
重构的时候，你必须去阅读代码，分析、理解逻辑，这样你就很可能发现一些逻辑或是简单的错误。而且重构的时候都要做一些必须的测试，也是有助于找到一些潜藏的错误的。
【重构有助于提高你的编程速度】
这个没有亲身体验过的人，估计只有一个形象的感受。我曾经参与到一个项目里面，那个项目简直到了你恨不得推翻它重写的地步。函数雍窘超长；代码到处堆砌；没用分层；逻辑耦合；通篇没啥注释。有时候你为了了解这个函数的功能，都要花费大量的时间和功夫。用同事的话说：“对这些代码望而生畏”。你想这样一个代码质量低劣的项目，做功能扩展、维护不拖累你的编程速度才怪。后来经过重构一部分代码后，才有所改善。
3: 什么时候重构？什么地方进行重构？
重构不应该特别划出时间进行，重构应该随时随地进行，不能为了重构而重构。而且我认为在在软件的生命周期里都要一直去重构，随时随地的重构。
三次法则(The Rule of Three)
第一次做某件事情时，只管去做；第二次做某件事件的时候，你可能会有些反感。但是你还是必须去做；第三次去做类似事情时，你就必须重构了。
具体到很细节的地方，作者提出了下面三条：
I： 添加新功能时重构
II： 修改错误时一并重构
III： 复审代码时一并重构
3：重构难题：重构时需要注意什么地方？
自己根据自己的经验总结了以下一些地方：有时候重构需要花费你大量的时间去处理，而且你动作过大时，往往改动的地方、修改的代码量让你简直要抓狂！，所以作者提倡的小步小步的慢慢重构是个不错的建议；重构往往会带入一些BUG，呵呵，做什么事情都是要付出代价的。这方面往往靠细心、和必要的测试量来控制；修改接口； 难以通过重构手法修改设计。
4：何时不应该重构？
⑴当开发进入尾声的时候，这时候不应该重构，因为这时候重构往往得不偿失，可能会引入错误，而且涉及的改动让你痛苦不堪，还会拖累项目交付时间。这时候只能等产品交付客户使用后慢慢重构
⑵有时候项目太混乱，你重构花费的时间可能比你推翻重新开发还花费时间。
