重构概述
新入职公司的第一个任务是重构现有的项目，正好之前阅读了《重构 改善既有代码的设计》一书，特此结合工作经历记录相关内容。
什么是重构？
先来说说我个人的理解，重构就是在保证代码现有功能的前提下让代码的风格、组织结构更加符合我个人的阅读、编写习惯。
当然，权威的定义是(《重构 改善既有代码的设计》中的定义)：
名词：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
动词：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构为什么要重构？
作为一个码农，日常工作就是解决问题。具体点不外乎定位问题、修复bug、开发需求(又名写bug)。而这些工作绝大多数都是基于已有项目或开源项目的代码，这就使得阅读代码成为工作中必不可少、占用时间极多的部分(不看直接上的同学请跳过此文)。
阅读代码十分重要，但又十分痛苦，尤其是面对一些特殊情况下产生的代码(作者比较忙、作者比较累、作者比较烦、作者比较怪…)，我们需要耗费大量的时间和精力来理解代码逻辑，从而修复问题或将需求逻辑添加到已有代码中。
为了让我们写出的代码即使在我们状态不好的情况下也能方便他人阅读，我们需要一些特殊的技巧，而重构就是让我们代码易于理解的技巧之一。只有易于理解，才能更好、更快的定位问题、修复bug、开发需求进而提高工作效率、解决更多的问题。
综上，重构是为了让代码易于理解，使代码面向阅读、面向变化(几乎没有代码是永远不变的)。
什么时候重构？
想什么时候就什么时候。好吧，这个是废话。其实重构并不一定需要特定的时间，在我们添加需求、review代码、修改bug的时候都可以重构。
当然，书中也强调如果已有代码过于混乱，那么就重新写一个(我现在干的事)。当然，时间不充裕的情况下，也尽量不要大面积的重构。
重构的重要性
重构并不只是名词、动词，更是一种思想，他可以改变我们的开发、工作思想，就像“永远不变的是改变”一样，重构让我们认识到在开发工作中，设计永远无法满足所有的场景，只有面向变化开发才能让程序有足够的健壮性。
学习了重构，当我们在面对繁杂的需求时，会保持一颗平稳的心。
怎么重构？
个人建议大家阅读《重构 改善既有代码的设计》一书，这本书对每种重构技巧都做了较为详细的声明，但是此书编写的时间较早，涉及到具体实现时不太符合现在的情况。
在此我就不一一说明了，感兴趣的读者可以必应或者google下，应该有大量此书描述的技巧说明。在此，我需要特殊说明的是，感谢IDE，使用IDE并不low，掌握不好IDE的使用才low，尤其是现在对重构支持的很好的各种IDE。