一切软件系统都是遗留系统

作者：戴夫·安德森（DaveAnderson）

即使系统十分前沿，采用了最新的技术开发而成，但对接手它的下一个人而言，它也会是遗留系统。必须应对这种情况！在今天，软件很快便会过时，这己经成为软件的天然属性。如果系统能够作为产品存活下来，哪怕只是数月时间，都必须承认一点：负责维护工作的开发人员肯定要对软件进行缺陷修复，这是不可避免的，这引出如下几个问题。

• 清晰性（clarity）：各个组件和类的角色一定要十分清楚。
• 可测性（Testability）：系统易于验证吗？
• 正确性（Correctness）：结果和设计或期望的一致吗？要避免那种虽然迅速但手段低劣（quick and nasty）的修复方式。
• 可跟踪（Traceability）：假设恩尼（Ernie）负责修复紧急缺陷，但此前他还从未看代码，他能马上跳入产品中诊断出故障所在并立马解决吗？还是需要8周的交接时间？

假设有另外不同的团队打开了代码库，他们很容易便可了解到当前在做什么，这是优秀架构的基础。无需对架构进行过度的简化或为之准备面面俱到的记录文档；好的设计会以多种方式说明自身。在生产环境中的系统行为也会说明其设计，举例而言，依赖关系十分丑陋的架构，其行为往往看起来就像是笼中的困兽，到处受限。替那些要进行缺陷调试的（通常都是较为初级的）开发人员着想一下吧。

在软件界，“遗留系统（legacy）”不是好词，但实际上，所有的软件系统都不应该排斥这个标签。它并不是一件坏事，因为这或许也表明了你的系统久经考验，符合预期，具有商业价值。任何软件系统，如果从未曾被称为“遗留系统”，那也许它早在发布前就己遭到被抛弃的厄运了，这可不是表明软件架构师取得成功的迹象。