编者按：遗留系统改造是程序员的宿命，据 IEEE 报道，自 2010 年以来，全世界的公司和政府在 IT 产品和服务上的支出估计为 35 万亿美元。其中，约四分之三用于运营和维护现有的 IT 系统。至少有 2.5 万亿美元用于尝试替换旧的 IT 系统，其中约有 7200 亿美元被浪费在失败的替换工作上。
为何互联网企业的遗留系统如此不堪？汇量科技技术 VP 兼首席工程架构师蔡超，将与我们分享其经验与建议。
引用蔡超加入汇量科技后，对其服务器架构进行了全面的调整，并最终实现了用云成本降低65%，戳【这里】了解更多
文/汇量科技技术 VP 兼首席工程架构师 蔡超
工作了快20年，很不幸，大多数的职业生涯都是在和遗留系统和重构打交道。有意思的是“重构”很多时候也成了我的标志，曾经是因为在 HP 成功重构了大型系统，才被挖到了 Amazon 。后来在 Amazon 又因为成功重构了全球 Dropship 系统，被很多团队邀请分享重构的经验。最有意思的是就算在 Amazon 这样的全球顶级IT公司，在分享重构时，每当我问到不同团队关于手上的遗留系统的问题时候，他们的答案几乎都是一样的：“遗留系统简直就是一坨屎”。可是不出意外的是很快他们重新构建的系统又变成了别人眼中的“另一坨屎”。
为什么我们眼中的遗留系统总会这么烂呢？经过了很多年持续地和遗留系统做斗争，我发现，“遗留系统是坨屎”的原因除了自身系统存在的问题，很多时候来还来自于一些固有的原因：
设计是一种取舍
大家对经典的 CAP 原则一定不会陌生，这就是一个取舍的经典范例。
当看到一个遗留系统的时候，我们更多会直接看到或感受到“舍去”的那部分。你也许会抱怨遗留系统的数据一致性有问题，但这反映了你可能忽略了这是当时为了水平伸缩性/更高可用性做出的妥协。有时你会觉得系统在性能上完全可以更好，这时我们可能没有了解当时对于成本和上线时间的妥协。
当然，如果我们修正了那些曾经被“舍去”的部分，通常就会影响曾经得到的部分，修正了一致性，结果可用性下降了；修正了性能，结果成本上升了。
读代码比写代码困难
和大家一样，每当我拿到一份遗留代码进行修改的时候，在心里会想无数次把它重写一遍。其实，这并不是统一编码风格就可以简单解决的，代码背后的设计逻辑远比代码本身要难理解得多。与代码风格相比，更好设计风格（如正确运用面向对象设计理念及设计模式等）更能够大大提高代码的可读性。
业务场景和技术的变更
随着企业的发展，系统所面对的数据量，用户使用方式等已经发生了变化，而当时的系统并不是根据现在的场景设计的。
同样，技术总是不停地向前演化，尤其是在云计算时代， AWS 每年都有上千个新的 features 发布，新技术往往会让遗留系统看起来有些落后。当然，犹如我在《十年架构感悟》中提到的，不要从技术出发，永远要从问题出发，寻找合适的技术去解决问题；而不是把新技术当个锤子，看什么问题都是钉子。
岁月的侵蚀
系统在构建完成后，经历了大大小小的修改，且很多时候这些修改并不一定能够遵循架构当初的风格，导致了架构的逐渐退化。并不是每个系统的维护者都真正了解架构的风格，很多时候的修改是一种短期的快速方案，而这样的修改越来越多，架构的风格也就被侵蚀了。
在这个已经高度信息化的时代，作为软件工程师，我想大多数人和我一样没有那么幸运总是能够去构建一个全新的系统（就算是有幸构建一个全新的系统，有一天也会变成遗留系统，变成别人眼中的“屎”），学会与遗留系统和平共处非常必要。
以上是一些个人感悟的分享，这里我推荐一本书 "Working Effectively with Legacy Code"，供大家拜读。
随着云计算时代下企业的不断发展，软件架构和代码也只能随之不断变化，遗留系统重构似乎成为了令人头疼的难题，未来我会和大家进一步讨论如何分析和重构遗留系统。（文/蔡超）
————————————
想要了解更多？访问 SpotMax 官网，并关注我们的公众号“云上说禅”吧！
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。