Suppressions of Suppressions — overreacted

TL;DR

文章探讨了代码检查中抑制规则的合理应用与风险。抑制规则可应对误报或遗留代码问题，但过度使用可能削弱代码质量和安全性。解决方案包括分层规则（如禁止关键规则被抑制）及团队协作机制：通过代码审查与自动化监控防止违规操作，明确责任分配，平衡开发效率与系统风险。

本文讨论了代码检查（linting）中抑制规则（suppressions）的合理使用与潜在风险，以及如何通过分层规则和团队协作来平衡代码质量与灵活性。

抑制规则的必要性
抑制规则允许开发者忽略某些静态检查错误，适用于规则本身存在缺陷、代码需逐步调整或历史遗留代码等场景，避免因误报或过渡限制影响开发效率。
过度抑制的风险
频繁使用抑制可能导致关键规则被忽略，例如性能或安全性规则被绕过，可能引发系统崩溃或性能问题。
解决方案：二阶规则
通过引入新的lint规则，禁止对特定关键规则的抑制。例如，Facebook曾采用此类实践，第三方工具（如eslint-plugin-eslint-comments/no-restricted-disable）也提供类似功能。这些规则强制开发者遵守核心规范，防止危险操作。
漏洞与补充措施
部分开发者可能同时抑制二阶规则和原规则。为此需结合以下措施：
- 代码审查：明确团队共识（如“禁止随意抑制关键规则”），并要求违规提交需经过配置规则的维护者审核。
- 自动化监控：追踪新添加的“双重抑制”并自动生成待办任务，或要求抑制注释关联任务单；对关键抑制设置强制审批流程。
社会契约的重要性
工具设计需融入团队协作模式，包括规则演进机制、责任分配（如谁维护规则）、代码结构与组织结构的对应关系，以及如何平衡功能开发与质量保障。有效的团队协作机制可转化为工具设计中的隐性规则，避免系统性风险。