1.重构和核心思想

我们一直在强调，程序中我们要不断的进行代码的重构，但是重构作为一种高度的脑力活动确实不易。为什么重构在一般的团队中不易推进呢？究其原因我认为有两方面的原因，第一、项目执行计划中不包括，团队只想更快的看到结果，没有规定时间用来重构，程序员可能有这方面的意识但是做了又不加入绩效所以也没有主动去重构的行动了。第二、没有一个统一的标准，每一个具体的开发人员都会按照自己认为的标准去编写代码实现功能，导致了编写出来的程序代码水平不一致。我认为这两方面原因是阻碍重构的主要原因。

为什么要做重构呢？站在项目长远发展的角度来看重构可以保持项目不被频繁的修改腐化了架构，确保在下一次需求变更的时候能够更加灵活快速的实现功能而会不引起过多的改变。那么我们进行重构工作应该遵循的原则是，“在不改变功能的前提下，优化其内部结构。”。

2.代码的坏味道

任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优秀的程序员。那么我们怎样进行代码重构呢？要进行代码重构前提是能够找到适应的切入点，敏锐的嗅觉闻到代码的坏味道。什么是敏锐的嗅觉呢？前提条件是我们对设计模式的6大原则比较清楚了并且熟悉业务需求。

我们可以从架构和代码两个方面来发现代码坏味道了，怎样发现架构的坏味道呢？一般来说架构设计是程序搭建的基本骨架，在架构层面，要对系统功能的划分，数据存储方案设计，物理部署设计，运行设计和开发使用的架构这五方面进行设计。如果程序在开发过程中发现现有系统的逻辑功能已经超出了原先界定的范围，那么我们就发现一处坏味道了。如果开发架构中原本规定使用三层架构，但是开发中却出现了两层或直接访问数据库的情况都是不符合规范的坏味道。另一方面就是从代码编写上面，我们要把代码写的尽可能轻易被阅读，代码的编写应该使用设计模式6大原则进行检验。项目的坏味道及早发现及早修改保持项目在预期设计范围之内。

3.重构的步骤

差劲的系统是很难修改的，因为很难找到修改点。如果很难找到修改点，程序员就很有可能犯错，从而引入Bug。重构这件事让那些已经能够运行的差劲的系统是没有人愿意去进行内部结构的优化。如果非得重构这样子的富有挑战性的系统，那么采用这几个步骤可以极大的降低重构中引入新的BUG。

每当我要进行重构的时候，第一个步骤永远相同，得为即将修改的代码建立一组可靠的测试环境。因为我们都是人，我们要把自己当人看，是人就不可避免会犯错，所以我需要可靠的测试（自我检验能力）。

当建立完一套完善的测试环境之后，我们以可以一步一步进行代码内部结构的优化了，不要追求一步能够把代码优化得非常成功，保持小步快走的不断对代码进行优化。