前端工程规范落地：规则少一点，但必须能执行

前端工程规范落地规则少一点但必须能执行一、规范失败通常不是写得不够多很多前端团队都有厚厚的工程规范但真正落地时没人看。原因不是规范不够完整而是规则太多、太虚、不可自动化。规范如果不能进入工具链最后就会变成会议纪要。有效规范应该少而硬。命名、目录、组件边界、状态归属、样式层级、测试要求和性能预算这些能影响长期维护的规则要明确。个人偏好类规则不要混进去。二、规范要进工具链flowchart LR A[规范文档] -- B[ESLint] A -- C[Stylelint] A -- D[TypeScript] A -- E[CI 门禁] E -- F[PR Review]能自动检查的规则尽量交给工具。格式化交给 Prettier基础错误交给 ESLint类型边界交给 TypeScript样式问题交给 Stylelint包体预算交给 CI。人工 Review 应该关注工具难以判断的问题比如组件抽象是否合理、状态是否放错层、业务语义是否清楚。不要把 Review 时间浪费在缩进和引号上。三、规则要有例外流程rule: name: no-large-component limit_lines: 300 exception: require_reason: true expire_days: 30没有例外的规范会被绕过。有些场景确实需要临时突破规则比如迁移期、历史包袱或业务紧急修复。关键是例外要记录原因、负责人和过期时间。// eslint-disable-next-line local/no-large-component -- 迁移期临时保留待表单拆分后移除禁用规则必须写原因。没有原因的 disable应该在 CI 里失败。规范要允许现实存在但不能允许债务匿名存在。四、规范要定期删减rarely_triggered high_noise - 删除或降级 often_triggered real_bug - 保留并强化规则不是越多越专业。长期没有触发、误报很多、无法解释价值的规则要删除或降级。能真实减少 bug 的规则要保留并沉淀案例。规范维护也要有 owner。工具升级、框架变化、目录调整后规则需要跟着更新。没人负责的规范会慢慢和项目现实脱节。新规范上线要给迁移窗口。老代码不可能一天变干净可以先对新增代码严格对存量代码只做告警。配合自动修复脚本和迁移任务团队更容易接受。规范落地最怕一上来全量阻塞最后大家只想关掉它。规范还要有正例仓库。只写“不要这样”不够团队需要看到推荐目录、组件拆分、状态管理和测试写法。正例能减少理解偏差也能让新人更快进入同一套工程语境。最后要把规范和事故复盘连接。线上问题如果来自缺失规则就把经验沉淀成工具或 checklist如果规则没有防住问题就调整规则。规范不是静态文档而是团队从真实问题里提炼出来的防线。指标也能反向验证规范价值。比如 PR 平均评论数下降、重复问题减少、构建失败更早暴露、线上样式回归减少这些都说明规范在发挥作用。如果规则很多但这些指标没有改善就要怀疑规范是不是只增加了流程噪音。规范的表达要具体。不要写“组件要优雅”“代码要清晰”这种无法执行的话而是写“跨页面状态必须说明 owner”“新增第三方依赖必须给出包体影响”。能被检查才算规范。五、总结前端工程规范落地要少而硬能自动化的进入工具链不能自动化的留给 Review。例外要可追踪规则要定期删减。规范不是展示团队专业的装饰品。它的价值在于减少沟通成本让代码库在长期迭代中保持清醒。