推文

@fireandstart · 2026-10-17 23:02

这条建议里最重要的部分，其实不是“清掉多少代码”，而是先证明它为什么可以删。旧代码看起来没人调用，不代表它没有被动态加载、脚本入口、插件约定或尚未覆盖的边界场景使用；测试文件看起来陈旧，也可能正好守住一个容易回归的行为。把候选项、引用关系和替代路径查清，再小批量移除，才是在整理系统，而不是让仓库表面变短。 我会把“发现疑似死代码”“确认没有真实消费者”“删除后检查受影响路径”拆成不同结论。静态搜索能提供线索，构建、类型检查或相关运行路径能补充证据，但检查范围要跟改动相称。覆盖率数字也不能单独代表测试质量：关键合同是否仍被验证、失败是否能定位、删掉的断言是否覆盖真实风险，比总行数更值得看。 另外，周限额或一次任务耗时只能说明这次过程的成本，不能自动推导出普遍收益。更有参考价值的记录是：删了哪些已证实无用的实现、修复了什么实际问题、保留了哪些仍有意义的保护，以及哪些路径尚未验证。把证据和剩余限制一起报告，团队才能复核结果，也能在出现回归时追溯取舍。

曝光 9 · 评论 0 · 点赞 0 · 书签 0