Meta 的系统代码和资产删除框架 (SCARF) 有一个用于识别和删除死代码的子系统。
- SCARF 结合了程序的静态和动态分析，从业务和编程语言的角度检测死代码。
- SCARF 自动创建更改请求，删除从程序分析中识别出的无效代码，从而最大限度地降低开发人员成本。
代码分析
SCARF 的代码分析子系统从各种来源收集信息。首先，通过Glean从我们的编译器中提取每种语言的代码依赖关系图。然后使用更多信息进行扩充，例如操作日志中 API 端点的使用情况，以确定是否在运行时使用端点。特定领域使用编码的其他示例包括：
- 内部开发人员工具和系统管理命令的脚本调用。
- 用于在 Instagram Django 后端动态渲染页面以及 URI 处理程序和路由的模板挂钩。
- 异步的动态引用的调度方法（Meta 的延迟作业执行服务）。
除了静态依赖图之外，SCARF 还必须能够内省任何和所有类型的动态使用，以准确确定一段代码是否真正可以安全删除。这些组合起来形成一个增强的依赖图。
SCARF支持多种编程语言。这非常重要，因为 Meta 的产品可能有用 Java、Objective-C 和 JavaScript 编写的客户端代码，用Hack编写的服务器代码，以及用Python编写的一些后端基础设施。所有这些代码片段都应该被删除，因为它们全部组合起来形成相同的依赖关系图，因为它们是通过 API 和其他已知形式的动态和跨语言引用关联的。
SCARF 在 符号级别而不是文件级别运行，这允许更精细的分析和清理。例如，函数中未使用的单个变量将具有其自己的完全限定符号，这允许比文件级别更精细的清理。
垃圾收集
SCARF通过分析增强依赖图来识别不可达的节点和可以删除的子图，并每天自动生成代码更改请求以删除相应的代码。分析完整图表的一个主要好处是我们可以检测和删除循环，其中代码库的不同部分相互依赖。删除整个子图可以加速删除死代码，并为在弃用中利用此自动化的工程师提供更好的体验。
图表包含增强的信息非常重要，因为单独的静态分析可能无法揭示通过动态引用或运行时语言功能创建的组件之间的链接。不过，存在一个权衡，即使用动态使用信息来增强图表需要对索引代码以及提供指标的后续数据分析管道进行全面处理。这会增加整个过程的端到端持续时间，从而使新特性或功能的原型设计变得更加困难。
删除死代码就足够了吗？
SCARF 的自动死代码删除加速了关闭和删除已弃用产品的代码和数据的过程，但并没有完全解决这个问题。除了互连性造成的问题之外，我们还在不断提高 Meta 跨所有语言、系统和框架集成的能力。准确地涵盖使我们的系统能够确定什么是真正死亡的代码和数据的每种类型的使用是很困难的。