一、旧系统
即任何已经存在的、难以维护或难以扩展的项目。
系统特点：
1）老旧
通常经历几年的时间，同时也会经历几代的维护人员，在他们交接的过程中，很多关于系统的初始设计和以前维护人员的意图和知识会被遗漏。
2）庞大
项目越大越难维护，需要理解的代码越多，存在的bug越多，而新的修改造成回归问题的可能性越大。因为新的修改会潜在影响更多现有的遗留代码。
3）继承而来
从以前的开发人员或者团队继承下来的，最初写这些代码和现在维护代码的人员并不是同一群人，甚至在他们之间可能隔着几代开发人员，这意味着，现在的维护人员无法知道为什么这些代码会以现在的方式工作，他们往往只能被迫去猜测最初写这些代码的人的意图及其隐含的设计假设。
4）文档不完善
无法完全信赖现存的技术文档，因为开发人员不一定保持对文档的更新。
代码特点：
1）没有测试和无法测试的代码，测试比文档有用，因为它们更有可能和系统实际的行为保持同步。
2）被技术债务拖累，开发人员偶尔都会对写些明知不够完善的代码感到内疚，但这些代码在当时又是足够用的。
二、面对
害怕修改
1）每当更改了一行代码，就会破坏一些根本不相关的东西，这些代码实在太脆弱了，根本无法工作。
2）如果没有绝对必要，不要碰任何相关的代码。对代码的恐惧往往是对未知的恐惧，因为不知道这些代码在做什么，它是如何做的，以及它如何链接到你更熟悉的部分。
三、为什么不重写
风险
1)bug的数量可能会多到让人无法接受的程度。
2)即使软件稳定并且没有bug，它的功能可能也跟用户想要的不一致。
3)项目可能需要比原计划更长的时间来完成，导致其超出预算。
4)有可能项目进行到一半，你才发现这个架构基本上是不可行的，并最终放弃你到目前为止写的所有代码。
5)更糟糕的情况是，可能直到向用户发布软件，你都没能意识到这些架构上的问题，并最终发现它在负载下是完全不稳定的。
6)从业务利益相关者的角度判断，它没有足够的吸引力。
重写的必要条件 1.尝试过重构并且失败了2.编程语言的转变，旧的开发语言濒临淘汰。
四、重构
好处：
增加了对代码的理解，探索得越多，就越了解代码，恐惧就会越少。
提高了代码的可读性，至少在单个类和方法的层次上，对提高代码的可读性有显著的改进，这些改进是累积起来的。
流程：
如果重构的规模小，不用繁琐的授权流程。如果预计时间超过一周，申请组织批准，向业务方的利益相关者解释为什么重构能为组织带来长远的利益。
1）使未来实现新功能X成为可能
2）将功能Y或系统性能提高多少
怎么做
1）借助版本控制系统、IDE工具
2）结对编程，引入同事代码评审
3）划定重构代码区域
4 ) 移除陈旧代码。它使代码更容易理解，因为需要阅读的代码更少了；它减少了人们浪费时间去修复或重构已经不再使用的代码的机会。如注释代码、过期代码、功能取消的。
5 ) 设计模式。使用标准设计模式将业务逻辑与实现细节分离，或者使复杂的业务逻辑更易于管理和组合。
6 ) 自动化测试。自动化运行尽可能多的测试
五、参考文献
整理内容来源于人民出版社-《遗留系统重建实战》