定义什么是遗留系统？
不经过充分测试的代码或者系统，称为遗留系统。
background：
在《你的代码是怎么变混乱的》？
代码是会随着时间腐化的，无论是有意的，还是无意的，即便是最理想的场景，代码设计的很好，维护的也很精心，但随着技术的不断进步，系统也需要逐步升级换代。
problem：
系统不断升级改造是不可避免的事？
问题是，你连自己三个月前写的代码都不愿意维护，那当面对庞杂的遗留系统时，又该何去何从呢？
重写真的是一种灵丹吗？
不经思考的重写，就像买彩票一样，运气好才能写好，但大多数人没有这么好的运气，我们不能总指买彩票中大奖改变生活，那有什么扫尾靠谱的一点的路呢？
分清现象与根因
Where are we?（我们现在在哪？）
Where are we going?（我们要到哪儿去？）
How can we get there?（我们如何到达那里？）
第一个问题： 面对遗留系统，我们的现状是什么呢？
对于现状的讨论，我们关心的比较少。因为大多数情况下，现状都是很明显的，但这一次不一样，也许你会说，不就是遗留系统，烂代码。
遗留系统和烂代码到底是不是问题？其实并不是，他们只是现象，不是根因
keys
在动手改动之前，先分析一下，找到问题的根因。
例子： 实现一个直觉需要两天的需求，需做到两周或更长时间，根本原因是代码耦合太严重，改动影响的地方太多；再比如，性能优化遇到瓶颈，怎么改延迟都降不下来，根因是架构设计的有问题，等等。
如果不进行根因分析，你很难确定问题到底出在哪，更关键的是，你无法判断重写是不是真的解决问题。
如果是架问题，你只是进行模型的调整是解决不了问题的，同样，如果是模型不清楚，你再优化架构也是浪费时间，
找到问题的根源：防止自己重新走上老路。
确定答案
1.假设找到遗留系统中存在的问题的根因，顺利地回答了第一个问题。接下来，我们来回答第二个问题，目标是什么。对于遗留系统而言，这个问题反而是最好的回答：
重写某些代码
强烈建议：
先尝试重构你的代码，尽可能在已有代码上做小步调整，不要走到大规模改造的路上，因为重构的成本是最低的。
我们的关注点在于第三个问题：
怎么做？我们需要将目标分解一下。
要重写一个模块，这时，你需要思考，怎么才能我们重写的代码和原来的代码功能上是一致的，对于这个问题，唯一靠谱的答案是测试。对两个系统运行同样的测试，如果返回的结果是一样的，我们就认为他们的功能是一样的。
不管你之前对测试是什么看法，这个时候，你都会无比希望自己有了大量的测试。如果没，你最好先给这个模块补充测试，因为只有当你构建起测试防护代码。后续的修改才算是在走坚实的道路上。
关于遗留代码的定义：
遗留代码就是没有测试的代码，按照这个定义，标准，很多团队写出来就是遗留代码，换言之，自己写代码就是在伤害自己。
怎么去替换遗留系统？
分成小块，逐步替换。任务分解思想在发挥作用。
tips：
按照分模块的做法，将新代码放到新模块里，按照新的标准去写新的代码/比如，测试覆盖率要达到100%，然后，让调用入口的地方依赖于这个新的模块。
新代码怎么写？
回到一开始的地方，我们为什么要做这次调整。因为这个系统已经不堪重负了，那我们所做的修改是不是一定能解决这个问题？答案是不好说。
很多程序员都会认为别人给留下的代码是烂摊子，但真有一个机会让你重写代码，你怎么保证不把摊子弄烂？
这是很多人没有仔细思考过的问题。如果你不去想这个问题，即便今天你重写了这段代码，明天你又会怨恨写这段代码的人没把这段代码写好，只不过，这个被抱怨的人是你自己而已
要想代码腐化的速度不那么快，一定要在软件设计上多下功夫，一方面，建立好领域模型，另一方面寻找行业对于系统构建的最新理解
1.关于领域模型的价值，不少行业已经形成了自己在领域模型上的最佳实践
2.寻找行业中的最新理解，简言之，我们需要知道行业已经发展到什么水平？
比如说，今天做一个大访问量的系统，我们要用缓存系统，要用 CDN，而不是把所有流量都直接转给数据库。而这么做的前提是，内存成本已经大幅度降低，缓存系统才成为了标准配置。
拜 REST 所赐，行业对于 HTTP 的理解已经大踏步地向前迈进，CDN 才有了巨大的进步空间。而今天的缓存系统已经不再是简单的大 Map，有一些实现得比较好的缓存系统可以支持很多不同的数据结构，甚至支持复杂的查询。从某种程度上讲，它们已经变成了一个性能更好的“数据库”。
有了这些理解，做技术选型时，你就可以根据自己系统的特点，选择适合的技术，而不是以昨天的技术解决今天的问题，造成的结果就是，代码写出来就是过时的。
前面这个例子用到的是技术选型，关于“最新理解”还有一个角度是，行业对于最佳实践的理解。其实在这个专栏里，我讲的内容很多都是各种“最佳实践”，比如，要写测试，要有持续集成，要有自动化等等，这些内容看似很简单，但如果你不做，结果就是团队很容易重新陷入泥潭，继续苦苦挣扎。
既然选择重写代码，至少新的代码应该按照“最佳实践”来做，才能够尽可能减缓代码腐化的速度。
总之，改造遗留系统，一个关键点就是，不要回到老路上。
总结时刻：
只要产品还在发展，系统改造就是不可避免的，改造遗留系统，前提条件要弄清楚现状，知道系统为什么要改造。是架构有问题，还是领域模型混乱，只有知道根因，才可能有的放肆进行改造。
改造遗留系统，tips：
1. 构建测试防护网，保证新老模块一致
2.分成小块，逐步替换
3.构建好领域模型
4.寻找行业中关于系统构建的最新理解
网友评论