陆业聪

在测试中，我们通常把被测的元素（可能是组件、类、方法等）叫做 SUT（System Under Test），把 SUT 所依赖的组件叫做 DOC（Depended-on Component）。对于这种分支条件较多的代码，我们可以梳理需求文档（如果有的话）和代码，找出所有的路径，根据每个路径下各个字段的数据和最终的值，制定一张决策表。一个软件的自动化测试，可以从内部表达这个软件的质量，我们通常管它叫做内建质量（Build Quality In）。接缝的类型是指，通过什么样的方式来改变 DOC 的行为。

第四种策略是 Refactor 和 Rearchitect，它们是指在不改变系统外部行为的前提下，对代码或架构进行调整、优化，以偿还拖欠已久的技术债务、改善非功能需求、提升系统健康度。我们要结合当前遗留系统的现状和想要提升的目标，做综合判断，对于不同的模块，也可以选择不同的策略组合，来实现一个完整的业务目标。而 Replace 是指彻底淘汰应用程序的所有组件，去构建或购买新的软件，同时会考虑添加新的业务需求或移除某些旧的业务需求。对于尚可满足使用的遗留系统来说，这无疑是风险和成本最低的策略。

内在认知负载是指从事一项工作必须付出的努力，比如学习 Java 知识、前端知识等；外在认知负载是指知识呈现的形式，代码越糟糕、越难读，外在认知负载越高；相关认知负载是指人们要学习一个知识所要付出的努力，在软件开发领域就特指业务知识。你只需要判断一下，当前这个事物、活动、决策所增加的认知负载是否更有利于我们完成当前和以后的工作。如果有利（比如学习更多的业务知识），就增加这种认知负载；如果不利（比如读一篇晦涩难懂的需求文档），就减少这种认知负载。

判断遗留系统的几个维度：代码、架构、测试、DevOps 以及技术和工具。时间长短并不是衡量遗留系统的标准。代码质量差、架构混乱、没有测试、纯手工的 DevOps（或运维）、老旧的技术和工具，才是遗留系统的真正特点。我们从业界对遗留系统的定义中总结出了 4 个关键字：旧、过时、重要、仍在使用。然而人们对于遗留系统的认识存在一个普遍的误区，即时间长的系统就是遗留系统。