我们花了12年通过三次 acquisitions 来维护酒店分发平台。

相同的代码库。每次买家都不一样，每次都有200+的整合。今天仍然有35,000+个属性在其上运行。

让它继续运营的关键并不是架构的是。 而是在早期做出的决定，即记录每次整合的假设，如下图中所示，如果最终工程师从来没有接触过客户。

大多数遗留系统不是因为老旧而失败的。他们失败的是因为在建筑里不再有造就他们有意义的知识。

好奇其他人是什么看法。在团队轮换时保持系统可维护性最低估计的实践是哪些？