遗留系统与修改代码
尽管维基百科上对遗留系统的定义是:
一种旧的方法、旧的技术、旧的计算机系统或应用程序。
但是实际上，当你看到某个网站宣称用新的框架来替换旧的框架的时候，你应该知晓他们原有的系统是遗留系统。人们已经不想在上面工作了，很多代码也不知道是干什么的，也没有人想去深究——毕竟不是自己的代码。判断是否是遗留代码的条件很简单，维护成本是否比开发成本高很多。
- 几乎无法维护
- 代码遗失
- 逻辑不清
- 没有文档或者不够详细、看不懂
- 关键点遗失
在维护这一类系统的过程中，我们可能会遇到一些原因来修改代码。如《修改代码的艺术》的一书中所说，修改软件有四大原因：
- 增加特性
- 修复 Bug
- 改善设计
- 优化
当我们修改代码之后，我们将继续引进新的 Bug。
参考阅读
-《修改代码的艺术》
遗留代码
与我们生活息息相关的很多软件里满是错误、脆弱的代码，并且难以扩展。这就是我们说的“遗留代码”。
相信你也经常看到某某网站的架构之路，会发现其中一个很有趣的过程就是他们会把之前的架构抛弃掉。接着，他们又做了一个这样的系统，然后过些年这个 系统又被重做了。究其原因，会发现这个架构是在几年前设计的。在几年前，他是非常好的架构。但是随着时间的演变，他还是几年前的架构。这是为什么呢？
遗留代码
什么是遗留代码？
没有自动化测试的代码就是遗留代码，不管它是十年前写的，还是昨天写的。
从一个新手程序员到一个老鸟，我们的编程水平都在不断增加。但是我们过去写的代码一直都在那里，我们一直都没有足够的勇气去动它们。因为我们知道如果一不小心改错了什么，就会导致一些意外的 Bug。这些 Bug 可能会对我们的编程生涯造成一些影响。
我们不知道这样做的后果，是因为我们没有对原来的代码进行测试。如果代码都是经过测试的，那么我们在修改中出的错，都会在测试中加以体现。长此以往，没有人敢去修改这些代码。
既然它在旧的系统中工作得很好，那么我们就没有理由去修改它们。当有新的需求出现时，我们就可以重新设计一个新的系统。
如何修改遗留代码
即使是最训练有素的开发团队，也不能保证始终编写出清晰高效的代码。
然而，如果我们不去尝试做一些改变，这些代码就会遗留下去——成为遗留代码，再次重构掉。即使说，重构系统是不可避免的一个过程，但是在这个过程中要是能抽象中领域特定的代码、语言也是件不错的事。
修改遗留代码
So，如何开始修改代码？如《修改代码的艺术》一书所说，应该是下面的五个步骤：
- 代码修改点
- 找到测试点
- 打破依赖
- 编写测试
- 修改并重构
在有测试的情况下重构现有的代码才是安全的。而这些测试用例也是功能的体现，功能首先要得到保证了，然后才能保证一切都可以正常。不过，我更喜欢以下面三点概括他们：
- 守: 找到测试点。守，即保证原有的功能是正确的。在这基础上，我们需要添加测试
- 破: 打破依赖。会导致遗留代码的一个原因还有，原有代码的耦合度比较高。因此，我们需要去打破这些耦合，重新构建依赖。
- 离: 修改并重构。
不过，我想你只要有前面的那些步骤。你为什么还需要看这一章的内容呢？
参考书籍：
- 《修改代码的艺术》
- 《持续交付指南：修改代码的9条最佳实践》
网站重构
网站重构应包含结构、行为、表现三层次的分离以及优化，行内分工优化，以及以技术与数据、人文为主导的交互优化等。
从我所了解到的网站重构，它大概可以分为下面的几类：
- 速度优化
- 功能加强
- 模块重构
下面就我们来看这三类的网站重构
速度优化
通常来说对于速度的优化也包含在重构中
- 压缩 JS、CSS、image 等前端资源
- 程序的性能优化(如数据读写)
- 采用 CDN 来加速资源加载
- 对于 JS DOM 的优化
- HTTP 服务器的文件缓存
如对于压缩前端资源这一类的重构，不仅可以从代码层级来解决问题，也可以借由服务器缓存来解决问题。这时候就需要去判断应该由哪个层级来做这样的事 情——如果一件事可以简单地由机器来解决，但是由人来解决需要花费大量的时间，这时就应该交由机器来解决。而如果由人来解决是一个长期受益，并且成本比较 低的事，那么就应该由人来解决。如我们只需要在我们的构建脚本中引入 minify 库就可以解决的事，那么应该交由人来做。
如，采用 CDN、HTTP 服务器的文件缓存这一类应该交由机器来做。
同时像程序性能优化、JS DOM 优化都是应交由人来解决的事。特别是像程序性能优化，从长期来看可能是一件长期受益的事。当且仅当，我们遇到性能问题时，重构这部分代码才可能带来优势。 如果我们的网站访问量不是特别大，那么优化可能就是徒劳的。但是这种优化对于个人的成长还是挺有帮助的。
功能加强
一般来说功能加强，应该是由于需求的变动才引起对系统的重构需求：
- 解耦复杂的模块 -> 微服务
- 对缓存进行优化
- 针对内容创建或预留 API
- 添加新的 API
- 用新的语言、框架代替旧的框架(如 Scala, Node.js, React)
模块重构
深层次的网站重构应该考虑的方面
- 减少代码间的耦合
- 让代码保持弹性
- 严格按规范编写代码
- 设计可扩展的 API
- 代替旧有的框架、语言
- 增强用户体验