遗留系统与修改代码

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