新规范的理想与现实

节日刚来公司把隔壁业务线的一个主要骨干提拔成了前端组长。

新上任，他花了整整一个晚上。在内网的 Confluence 上写了一份👉 《前端团队研发协作与编码规范》。其实，

为了体现专业度。他还特意把文档链接发到了全员群里而且配置了非常严格的 ESLint 和 Husky 提交拦截。

我随手点开那份规范看了一眼。里面有一段关于网络请求和 TypeScript 类型的规定，写得非常理想主义😢。

我直接把原文档的部分片段。给你们摘录出来👇：

当时开会在投影仪上过这份文档时大家纷纷鼓掌说好，觉得咱们的代码终于能摆脱草台班子的气质，向大厂开源规范看齐了😁。

结果晚上临近发版，我帮他们组 Review 一段紧急合入的业务代码时差点笑出声。

理想中的规范是一尘不染的，但现实业务里的代码全是泥巴。我给你们看看，为了躲避这段严苛的规范，一线开发兄弟在提测倒计时重的压下写出的代码：

// 后端老哥下午临时改了表单的返回结构。把原本的数组改成了一个逗号分隔的字符串// 前端兄弟急着提测，但又被 Git Hook 死死卡住不让提交// 于是他为了绕过严禁使用 any的规范，写出了这种极其糊弄的声明：type MagicType = unknown;// 高级 any，完美骗过简单的 ESLint 扫描interface UserFormRes { userId: number;// 先 unknown 占位 dynamicExtData: MagicType;}const UserProfile = => { const = useState;老实说，const renderPrivilege = => { // 规范要求：必须用可选链。必须做类型兜底 // 于是业务层出现了一坨安全转换代码： const extStr = || '';const list = extStr.split.filter;// 强行把 boolean 转换回后端有时候乱传的 和 const isVip =?其实，.is_vip == '' || false;
说起来，return 

{/* 渲染逻辑 */}
}}

无法回避的现实问题

再去翻翻那一天的 Git 提交记录。原本规范里白纸黑字写着，Commit Message 必须是 feat: 更新详情。但大家被拦截规则搞烦了又不想去查具体的命令格式，于是那一晚的记录里满屏都是用快捷指令强行绕过的产物：

git commit -m "fix" --no-verify

看着新负责人在群里无奈地圈人。问大家为什么不按规范来我其实非常理解他的挫败感的🤔。

现实问题

在这个行当混了这么多年。带过好几个大大小小的团队，我见过太多这种死在摇篮上的技术规范。很多人总觉得，只要规矩定得细，配上拦截工具，大家就会乖乖就范。

但这忽略了一个最致命的现实：前端是直接扛业务压力的最终一环。

当产品经理站在你工位旁边，问你为什么这个按钮点下去没反应？测试在群里疯狂 @你，倒计时还有半小时就要封板上线。这个时候，你脑子里只有一件事：把逻辑跑通，让报错消失。

这时候谁有空去翻那十几页的文档，查一查这个嵌套了四层、连后端自己都说不清楚的 JSON 结构。到底该怎么老老实实写成 Interface？

//某个新人写在促销活动页面的代码useEffect => { //错误：在业务组件里直接裸写 fetch,绕过全局请求实例 fetch .n) .n) .catch;})，},);//依赖数组根据实际情况补充

别用规范去管人。用基建去管代码

// 所有的网络层交互,必须走基础封装import { http } from '@/utils/request';//统一的请求封装import { reportMonitor } from '@/utils/monitor';//统一的监控上报useEffect => { //必须通过全局 http实例调用。自动带上 Token,重试机制和全局拦截 http.get .n) .catch;})，},);//依赖数组根据实际情况补充