共计 1544 个字符，预计需要花费 4 分钟才能阅读完成。
编者按：遗留零碎革新是程序员的宿命，据 IEEE 报道，自 2010 年以来，全世界的公司和政府在 IT 产品和服务上的收入预计为 35 万亿美元。其中，约四分之三用于经营和保护现有的 IT 零碎。至多有 2.5 万亿美元用于尝试替换旧的 IT 零碎，其中约有 7200 亿美元被节约在失败的替换工作上。
为何互联网企业的遗留零碎如此不堪？汇量科技技术 VP 兼首席工程架构师蔡超，将与咱们分享其教训与倡议。
文 / 汇量科技技术 VP 兼首席工程架构师 蔡超
工作了快 20 年，很可怜，大多数的职业生涯都是在和遗留零碎和重构打交道。有意思的是“重构”很多时候也成了我的标记，已经是因为在 HP 胜利重构了大型零碎，才被挖到了 Amazon。起初在 Amazon 又因为胜利重构了寰球 Dropship 零碎，被很多团队邀请分享重构的教训。最有意思的是就算在 Amazon 这样的寰球顶级 IT 公司，在分享重构时，每当我问到不同团队对于手上的遗留零碎的问题时候，他们的答案简直都是一样的：“遗留零碎几乎就是一坨屎”。可是不出意外的是很快他们从新构建的零碎又变成了他人眼中的“另一坨屎”。
为什么咱们眼中的遗留零碎总会这么烂呢？通过了很多年继续地和遗留零碎做奋斗，我发现，“遗留零碎是坨屎”的起因除了本身零碎存在的问题，很多时候来还来自于一些 固有的起因：
设计是一种取舍
大家对经典的 CAP 准则 肯定不会生疏，这就是一个取舍的经典范例。
当看到一个遗留零碎的时候，咱们更多会间接看到或感触到“舍去”的那局部。你兴许会埋怨遗留零碎的数据一致性有问题，但这反映了你可能疏忽了这是过后为了 程度伸缩性 / 更高可用性 做出的斗争。有时你会感觉零碎在性能上齐全能够更好，这时咱们可能没有理解过后对于老本和上线工夫的斗争。
当然，如果咱们修改了那些已经被“舍去”的局部，通常就会影响已经失去的局部，修改了一致性，后果可用性降落了；修改了性能，后果成本上升了。
读代码比写代码艰难
和大家一样，每当我拿到一份遗留代码进行批改的时候，在心里会想无数次把它重写一遍。其实，这并不是对立编码格调就能够简略解决的，代码背地的设计逻辑远比代码自身要难了解得多。与代码格调相比，更好设计格调（如正确使用面向对象设计理念及设计模式等）更可能大大提高代码的可读性。
业务场景和技术的变更
随着企业的倒退，零碎所面对的数据量，用户应用形式等曾经产生了变动，而过后的零碎并不是依据当初的场景设计的。
同样，技术总是不停地向前演变，尤其是在云计算时代，AWS 每年都有上千个新的 features 公布，新技术往往会让遗留零碎看起来有些落后。当然，犹如我在《十年架构感悟》中提到的，不要从技术登程，永远要从问题登程，寻找适合的技术去解决问题；而不是把新技术当个锤子，看什么问题都是钉子。
岁月的侵蚀
零碎在构建实现后，经验了大大小小的批改，且很多时候这些批改并不一定可能遵循架构当初的格调，导致了 架构的逐步进化 。并不是每个零碎的维护者都真正理解架构的格调，很多时候的 批改是一种 短期的疾速计划，而这样的批改越来越多，架构的格调也就被侵蚀了。
在这个曾经高度信息化的时代，作为软件工程师，我想大多数人和我一样没有那么侥幸总是可能去构建一个全新的零碎（就算是有幸构建一个全新的零碎，有一天也会变成遗留零碎，变成他人眼中的“屎”），学会与遗留零碎和平共处十分必要。
以上是一些集体感悟的分享，这里我举荐一本书 “Working Effectively with Legacy Code”，供大家拜读。
随着云计算时代下企业的一直倒退，软件架构和代码也只能随之一直变动，遗留零碎重构仿佛成为了令人头疼的难题，将来我会和大家进一步探讨如何剖析和重构遗留零碎。（文 / 蔡超）
————————————
想要理解更多？拜访 SpotMax 官网，并关注咱们的公众号“云上说禅”吧！
