1 why

不管是从头是实现一个系统。还是维护一个系统，当时实现的技术可能是最先进的、规划的产品逻辑是合理的，随着时间的发展、开发者的变更、系统的代码质量会逐渐腐化，加个Feature太麻烦。改个Bug涉及模块太多-没有单測不敢随便解，业务方抱怨技术团队响应太慢。

是时候重构系统了。

对于技术团队来说，重构能力影响着系统对业务团队的响应速度。非常多职位招聘的时候都要求：

● 对已有系统进行重构和优化。

● 对组件的重用、重构有丰富的经验；

● 可以熟练运用各种重构方法；

● 察觉实现问题。提出改进（重构）方案；

● 对框架本身的体系有较为深厚的理解和应用经验，对框架本身有过开发或重构者可优先考虑

……拥有重构能力的技术人员在个人价值方面也有非常大的竞争力(^o^)/~

2 how

重构系统的时候。技术人员应该考虑对遗留代码、第三方代码、开源码、最新技术的合理利用。全然从零開始，在时间上、业务复杂度上都是不同意的。

依据个人开发经验。我觉得应该将重构分为：代码重构、模块重构、架构重构3个不同的类型。

代码重构：这个也系统业务关系比較少，很多其它的是优秀编码规则的遵循和实现。比如：统一的错误异常抛出和处理方案，易于理解的返回值模型，统一的入參验证规则。基于设计模式6大原则的编码，单測用例的补全和维护。这样的类型的重构更易实现。而且对现有业务员逻辑的没有影响。

模块重构：技术团队既要满足日常的需求开发，同一时候也要做到原有代码的重构。开发资源肯定是不够用的，比較可靠的方案是在选定一个和新需求相关的、而且和其它业务模块耦合度比較低的业务模块进行重构。又一次梳理业务流程和技术实现方案，这部分重构的实现依赖于代码重构，良好的编码规范和代码质量是基石。对相关业务的熟悉度则是骨架。整个流程一直迭代下去完毕整个系统的全部的模块的重构，这个过程中须要技术团队基于代码入手，从代码级思维跳到设计级思维，抽象出当前的设计模型。考虑适应各种场景带来的可扩展性、可维护性的压力了。

架构重构：这个是重量级的重构。假设按部就班的由代码重构->模块重构，前2个做好后，架构重构就非常自然非常easy的实现了：识别各种共用业务模块，抽取作为各种服务的基础。

假设一開始就又一次来做，当前业务需求要暂停，同一时候技术团队的开发压力非常大。须要大量的加班来降低对业务响应的阻碍。

參考：http://www.programmer.com.cn/4555/