问题的背景：在企业现代化倡议中，业务分析师经常遭遇 知识衰退—一种关键业务逻辑仅以不可读的遗留代码存在的现象。这个问题来自 大型机到云 的迁移，原来的架构师在几十年前就退休了，留下的 COBOL 程序可以完美执行，但无法解释。历史背景涉及从单体批处理转变为分布式 微服务，其中隐式状态管理必须变为显式的 API 合同。
问题集中在认识论的不透明性上：系统可以工作，但没有人知道为什么。COBOL 代码库包含默示的商业规则——边缘情况、监管补丁和手动覆盖——这些规则从未被文档化，因为原始开发者将其保存在记忆中。当前的运营人员理解输入和输出，但不理解决策逻辑。与此同时，新的 云原生 架构要求这些规则被解耦、记录，并通过 REST 端点公开以便于实时消费。固定的监管截止日期阻止了多年的考古挖掘，但规则提取中的错误可能违反 GDPR 数据处理规范或财务报告的准确性。
解决方案采用 三角反向工程 方法。第一，召开与运营人员的 事件风暴 研讨会，绘制可观察的商业行为并识别“黑箱”过程。第二，利用静态代码分析工具生成 COBOL 程序的 控制流图，将变量变更与业务结果进行交叉参考。第三，实施 并行运行的影子模式，新 微服务 过程在没有生产影响的情况下与遗留系统镜像交易，标记出不一致之处以供调查。这创造了一个反馈循环，代码考古验证了利益相关者的记忆，并且利益相关者的背景解释了代码异常。
一家地区保险公司需要将1980年代的 COBOL 保单评级引擎替换为 Python/FastAPI 微服务套件，以实现实时移动报价。原始计算逻辑包括复杂的区域风险加权、季节性调整因子和重保险条款，这些内容在四十多年的时间里被修补。剩下的三名 COBOL 开发者已退休，而当前的IT工作人员将系统视为一个“魔法箱”，能够生成正确的保费，但无法解释特定边缘情况的数学推导。监管机构要求在八个月内完成迁移，以避免不支持的基础设施处罚。
评估了几种捕捉需求的方法。第一个选项提出了一种 代码到规格的转录，开发者将手动文档化每一个 IF 语句和 MOVE 操作在 COBOL 源代码中的优点包括理论的完整性和确切逻辑的保留。缺点是严重的：代码库包含超过两百万行的意大利面条代码，全球变量未被文档化，这将是一个多年的工作，可能会错过截止日期，并且可能引入转录错误。
第二个选项建议 黑箱需求推导，观察输入（保单属性）和输出（保费金额）来通过统计回归推断规则。优点是速度快，关注当前业务价值而不是技术债务。缺点包括无法检测罕见索赔场景的休眠代码路径，以及将错误编纂为功能的风险。
第三个选项，行为考古与并行验证，涉及从五年的生产日志中提取样本数据，构建基于实际交易的决策树，并使用自动化差异工具将其验证与 COBOL 源进行比较。
团队选择了第三种解决方案，因为它在速度与准确性之间取得了平衡，同时尊重了敏捷原则，即优先考虑工作软件而不是全面文档化。通过聚焦于执行的代码路径而不是死功能，他们将范围减少了60%，同时确保活动商业规则被正确捕捉。他们建立了一个包含匿名历史交易的数据湖，并将这些数据通过遗留的 JCL 作业和新的 FastAPI 服务进行处理，自动标记出大于0.01%的保费计算不匹配。这揭示了三条关键的未记录条件：1992年之前发行的佛罗里达保单的飓风免赔金覆盖、退休代理人的特殊佣金计算，以及数十年来通过手动电子表格调整而“修正”的季度税务报告中的四舍五入错误。微服务 被重新设计为显式处理这些边缘情况作为可配置的商业规则，而不是硬编码的常量。
在反向工程遗留代码时，您如何区分关键业务约束和可以在迁移期间安全消除的技术变通？
候选人常常假设所有现有逻辑都服务于当前业务目的，陷入 沉没成本谬误 的遗留保存。正确的方法涉及 时间背景分析：检查代码变更的日期戳与已知的监管变更、合并或不再存在的技术限制进行关联。例如，COBOL 中的数据截断例程可能存在的唯一原因是原始的 DB2 模式使用了固定宽度字段，而现代 PostgreSQL 支持可变长度字符串——完全消除了截断规则的需要。业务分析师必须与业务利益相关者进行 意图验证会议，将怀疑的变通方案呈现为“我们可以通过去除 X 来简化这一点；这会影响您的合规性吗？”而不是问“我们应该保留 X 吗？”这将证明的责任转移到必要性而不是保存。
你如何防止"货船邪教"反模式，使得新系统只是因为存在于 COBOL 单体中而复制低效的批处理工作流？
许多候选人仅专注于功能平等，而忽视了 流程再工程。当业务分析师将当前状态（例如，“系统在凌晨2点运行批处理”）作为未来状态的要求进行记录时，失败就发生了，忽略了使用 Apache Kafka 或 RabbitMQ 的事件驱动架构可以使实时处理成为可能。解决方案需要 能力映射：将“什么”（风险计算必须发生）与 “如何”（批处理与流处理）分开。业务分析师应执行 价值流映射，以识别批处理调度中的等待时间，这些等待时间服务于操作便利，而不是商业规则。通过证明 REST 端点可以为承保人提供即时反馈——将报价到绑定时间从24小时减少到30秒——他们为可能会被驳回的架构变化提供了理由，这些变化“与旧系统相差太大”。
你用于量化和传达"未知未知"的风险的策略是什么——在您的样本数据观察期间从未触发的隐性规则，但在迁移后可能会灾难性地浮现？
候选人经常根据对历史数据的100%测试通过率向利益相关者提供虚假的信心。复杂的答案承认遗留数据中的 抽样偏差，主张对 合成场景进行压力测试。这涉及生成 模糊输入数据，以测试生产日志中未见的边界条件，然后比较 COBOL 和新系统的输出。此外，业务分析师必须在新的架构中建立 断路器模式：如果 微服务 遇到无法处理的交易结构（指示可能错过的规则），它应优雅地退化为调用遗留的 SOAP 包装器（如果可用）或标记以进行人工审查，而不是静默失败或默认设置为 null 值。沟通策略涉及 概率风险矩阵，显示尽管95%的规则已被验证，但5%的残留不确定性需要三个月的超关怀期，期间进行双倍的手动对账检查。