为什么每次加入一个新的团队，都会觉得遗留系统是一坨“屎”？

工作了快 20 年，很不幸，大多数的职业生涯都是在和遗留系统和重构打交道。有意思的是“重构”很多时候也成了我的标志，曾经是因为在 HP 成功重构了大型系统，才被挖到了 Amazon。后来在 Amazon 又因为成功重构了全球 Dropship 系统，被很多团队邀请分享重构的经验。最有意思的是就算在 Amazon 这样的全球顶级 IT 公司，在分享重构时，每当我问到不同团队关于手上的遗留系统的问题时候，他们的答案几乎都是一样的：“遗留系统简直就是一坨屎”。可是不出意外的是很快他们重新构建的系统又变成了别人眼中的“另一坨屎”。

为什么我们眼中的遗留系统总会这么烂呢？经过了很多年持续地和遗留系统做斗争，我发现，"遗留系统是坨屎"的原因除了自身系统存在的问题，很多时候来还来自于一些固有的原因：

1. 设计本来就是一种取舍。大家对经典的 CAP 原则一定不会陌生，这就是一个取舍的经典范例。

当我们看到一个遗留系统的时候，我们更多会直接看到或感受到“舍去”的那部分。你也许会抱怨遗留系统的数据一致性有问题，这时你可能忽略了这是当时为了水平伸缩性/更高可用性做出的妥协。有时你会觉得系统在性能上完全可以更好，这时我们可能没有了解当时对于成本和上线时间的妥协。

当然，如果我们修正了那些曾经被“舍去”的部分，通常就会影响我们曾经得到的部分，修正了一致性，结果可用性下降了；修正了性能，结果成本上升了。

2. 读代码本来就比写代码困难。我和大家一样，每当拿到一份遗留代码进行修改的时候，会有无数次在心里想把它重写一遍。其实，这个并不是统一编码风格就可以简单解决的，代码背后的设计逻辑远比代码本身要难理解得多。与代码风格相比，更好设计风格（如正确运用面向对象设计理念及设计模式等）更能够大大提高代码的可读性。

3. 业务场景和技术的变更。系统所面对的数据量，用户使用方式等已经发生了变化。当时的系统并不是根据现在的场景设计的。

同样，技术总是不停地向前演化的，尤其是这个云计算时代，AWS 每年都有上千个新的 features 发布，新技术往往会让遗留系统看起来有些落后。当然，犹如我在《十年架构感悟》中提到的，不要从技术出发，永远要从问题出发，寻找合适的技术去解决问题；而不是把新技术当个锤子，看着什么问题都是钉子。

4. 岁月的侵蚀。系统在构建完成后，经历了大大小小的修改，而很多时候这些修改并不一定能够遵循架构当初的风格，导致了架构的逐渐退化。并不是每个系统的维护者都真正了解架构的风格，很多时候的修改就是一种短期的快速方案，而这样的修改越来越多，架构的风格也就被侵蚀了。

在这个已经高度信息化的时代，作为软件工程师，我想大多数人和我一样没有那么幸运总是能够去构建一个全新的系统（就算是有幸构建一个全新的系统，有一天也会变成遗留系统，变成别人眼中的“屎”），学会有效的和遗留系统工作是非常必要。未来我还会和大家进一步的讨论如何分析和重构遗留系统，这里我先推荐一本书 “Working Effectively with Legacy Code"

欢迎关注我的公众号，工程师间的真挚交流