什么时候重构？
重构是一种习惯，一种编程习惯。这种习惯让我们迅速由菜鸟转变为大牛，可以编写出高质量、优秀的程序。
问题的关键就是降低修改成本与风险的方法，而这个方法就是系统重构。
走出重构的第一步对每一个人来说都是一次心灵的考验，甚至许多人总是徘徊于路口踌躇不前，但一旦跨出去了，它将成为你生命的一部分。
没有经过重构的，原生态的代码是没办法复用的，当我们发现代码需要复用时，切忌不要使用过去那种简单粗暴的复制黏贴，合理运用重构方法，加之以仔细、认真、即时的测试，就可以保证既有代码的正确，并使整个系统合理地复用起来，以提高系统的可维护性，关键是你有没有这样的意识。
添加新功能前线重构原系统，其目的有两个：
1. 软件的设计总是与软件的复杂度有关的，原有的设计师在原有需求不复杂的条件下做出的，但随着新功能的加入，软件复杂度在发生着变化，因此必须调整原有的设计。
2. 为了提高软件的可维护性与易变更性，添加新功能应遵循OCP原则。
系统重构是我们维护处高质量遗留系统的有效工具。
在紧急变更任务中，时间就是金钱，我们要用最省时省力的方法解决问题，这里的差别就是怎样去重构？——做完整的设计， 但只做重构中最紧急的部分。
测试驱动开发
测试驱动开发是极限编程的一个重要组成部分，它的核心思想非常简单，就是先写测试用例再编码。
后测试开发即先进行完备的软件设计，然后进行完备的软件编码，当几乎所有程序都设计开发完成后才开始相应的测试。这样的模式，从设计到测试的时间比较长，造成运行调试与测试的难度大，发现问题后的问题定位及修复的难度大，因而延长了软件开发的周期。
标准的测试驱动开发步骤：
1. 编写测试程序，此时的测试程序必然无法编译或者无法测试通过
2. 编写要实现的程序代码，使测试程序得以通过
3. 在测试程序的保护下重构代码，使其得到优化
4. 重复以上过程，使开发工作不断进行下去
有了测试程序的保护，我们可以大胆地尝试重构，使系统的代码质量得到提高。
当我们的项目开始进行新一轮开发时，首先对涉及的、需要修改的程序建立测试程序。当原有功能的测试程序建立起来并测试通过以后，我们开始添加新的代码。在添加新的代码前，按照测试驱动开发流程，先在原有测试程序的基础上添加新的测试用例。新的测试用例将体现系统的新功能，但此时的测试程序必然报错或无法测试通过，随后我们开始实现新功能，此时的程序可能不是最优的，只是能够保证测试程序的通过。接着我们开始思考并尝试重构来优化我们的设计。如此往复，直到完成所有开发。
分析既有代码的程序结构，用草图形式绘制出静态类图。在类图中绘制出相关的接口与类，主要的属性和方法，以及它们之间的关系。
全面的升级任务
演进式设计的核心思想是快速反馈：快速设计，快速开发出可运行的程序，快速测试，快速验证。演进式设计最大的问题是缺乏一种长远的规划。每次演进仅仅考虑此次功能的实现，最后设计成什么样子没有一个方向性的规划。
恰如其分的规划，就是对遗留系统目前的状况，面临的风险，可采用的措施进行一次恰如其分的数据收集与分析，有针对性地制定改造范围、执行阶段与打到的目标。
风险驱动设计时以风险的分析与识别作为核心，用最小的代价去完成最急迫的风险，从而达到恰如其分的设计开发的一种软件设计方法。该方法适用于以系统改造为目的的研发项目。
三类风险：
1. 我们缺乏对该系统相关知识的掌握，程序修改与维护变成一种冒险。
2. 维护成本越来越高，任何的变更都变得伤筋动骨。
3. 最后一个，也是最可能促使企业痛下决心进行系统改造的原因，那就是旧技术已经不能满足用户新的需求，我们必须要进行新技术的转型。
识别风险才能让我们更加有效地去规避风险，从而更加有针对性地进行系统改造，避免系统重构工作特别容易出现的”想到哪里就做到哪里“的弊病。