发现一个很有意思的情况，做系统写代码多年了，遇到的需求基本上是在已有的系统上实现，从头来实现的系统基本上没有。
无论是从头是实现一个系统，还是维护一个系统，当时实现的技术可能是最先进的、规划的产品逻辑是合理的，随着时间的发展、开发人员的变更、系统的代码质量会逐渐腐化，加个Feature太麻烦，改个Bug涉及模块太多-没有单测不敢随便解，业务方抱怨技术团队响应太慢。是时候重构系统了。
对于技术团队来说，重构能力影响着系统对业务团队的响应速度。很多职位招聘的时候都要求：
● 对已有系统进行重构和优化；
● 对组件的重用、重构有丰富的经验；
● 能够熟练运用各种重构方法；
● 察觉实现问题，提出改进（重构）方案；
● 对框架本身的体系有较为深厚的理解和应用经验，对框架本身有过开发或重构者可优先考虑
……拥有重构能力的技术人员在个人价值方面也有很大的竞争力(^o^)/~
重构系统的时候，技术人员应该考虑对遗留代码、第三方代码、开源代码、最新技术的合理利用，完全从零开始，在时间上、业务复杂度上都是不允许的。
根据个人开发经验，我认为应该将重构分为：代码重构、模块重构、架构重构3个不同的类型。
代码重构：这个也系统业务关系比较少，更多的是优秀编码规则的遵循和实现。例如：统一的错误异常抛出和处理方案，易于理解的返回值模型，统一的入参验证规则，基于设计模式6大原则的编码，单测用例的补全和维护。这种类型的重构更易实现，并且对现有业务员逻辑的没有影响。
模块重构：技术团队既要满足日常的需求开发，同时也要做到原有代码的重构，开发资源肯定是不够用的，比较可靠的方案是在选定一个和新需求相关的、并且和其他业务模块耦合度比较低的业务模块进行重构，重新梳理业务流程和技术实现方案，这部分重构的实现依赖于代码重构，良好的编码规范和代码质量是基石；对相关业务的熟悉度则是骨架。整个流程一直迭代下去完成整个系统的所有的模块的重构，这个过程中需要技术团队基于代码入手，从代码级思维跳到设计级思维，抽象出当前的设计模型，考虑适应各种场景带来的可扩展性、可维护性的压力了。
架构重构：这个是重量级的重构，如果按部就班的由代码重构->模块重构，前2个做好后，架构重构就很自然很容易的实现了。如果一开始就重新来做，当前业务需求要暂停，同时技术团队的开发压力很大，需要大量的加班来减少对业务响应的阻碍。
参考：http://www.programmer.com.cn/4555/
原文地址：http://blog.csdn.net/liu251/article/details/42060105
