我如何实现死端点检测自动化并从我们的 Node.js 代码库中删除了 16,000 行代码

Source: Dev.to

Problem

八年的产品迭代在我们的 Express API 上留下了痕迹。它已经膨胀到 45,000 行代码，跨越数百个端点——已经上线的功能、未上线的功能、被替换的集成、被放弃的实验。没有人确切知道哪些仍在被使用。

静态分析并不是答案。ESLint 之类的工具可以告诉你代码层面上哪些是不可达的，但它们无法判断一个端点是否在实际生产中收到流量。一个端点在代码中可能完全可达，却在生产环境中彻底死亡。我们需要一种不同的信号。

Initial Manual Process

我们先从访问日志入手，手动完成第一遍筛选。通过将日志数据与已注册的 Express 路由交叉比对，我们找出了候选——在数月内零流量的端点——然后在动手之前手动验证每一个。

这个过程证实了方法的可行性：我们手动删除了 12 个端点。然而，手工操作难以规模化。验证速度慢，交叉比对繁琐，且仍有数百个端点待处理。

Automated Detector

我们构建了一个检测器，实现了日志分析的自动化。它：

• 摄取 访问日志。
• 提取 在可配置的观察窗口内收到流量的每条路由。
• 映射 与 Express 应用中注册的所有路由进行对比。
• 输出 带有元数据的候选列表：最近一次出现的日期、随时间变化的调用量，以及在暗淡之前调用它们的服务或客户端。

检测速度很快。验证仍然需要人工——有些看似死亡的端点实际上被季度任务、旧版移动客户端或不出现在主流量日志中的内部脚本调用。但自动化输出让验证速度大幅提升，因为你是在审阅已有证据，而不是去寻找它。

Results

代码库现在更易于浏览，入职更快，重构时也不再让人望而生畏。

Lessons Learned

最难的部分不是检测本身，而是害怕出错。每个在遗留代码库中工作的工程师都懂这种感觉——一个端点看起来已经死亡，日志也证实了，但如果它每年只被某个没人记得的流程调用一次呢？

答案是延长观察窗口并使用验证检查清单，而不是陷入瘫痪。如果一个端点在生产、预发布和金丝雀环境中整整 12 个月都没有流量，并且在任何计划任务、脚本或运行手册中都没有引用——它就是死亡的。直接删除它。

Future Work

我们正在探索将其打造为面向 Node.js/Express 代码库的独立工具。如果你的团队正面临同样的遗留 API 问题，欢迎告诉我们你是如何处理（或未处理）的。