上上周，我们在例会上送别了团队里的一位技术大牛——阿K。
说实话，他真的很强。
- 能手写 Webpack 插件
- 熟读 ECMA 规范
- 对 Chrome 渲染管线倒背如流
属于那种面试官一看到就眼睛发光的选手。
但最终，CTO 还是决定劝退他。
理由很残酷，只有一句话：
你的代码，团队里没人敢接手。
那一刻，会议室安静得可怕。
01 灾难是从一次“性能优化”开始的
事情起因很普通。
我们在重构一个后台管理系统，阿K 负责最核心的权限校验模块。
需求本身极其简单：
后端返回权限列表，前端判断用户有没有某个按钮的权限。
换成代码，大多数人（比如我）会这么写：
// 一眼就能看懂
const hasPermission = (userPermissions, requiredPermission) => {
return userPermissions.includes(requiredPermission);
};
if (hasPermission(currentUser.permissions, 'DELETE_USER')) {
showDeleteButton();
}
清晰、直白、没有任何炫技。
结果 Code Review 时，阿K 露出了一个“你们还是太年轻”的表情 ：
includes 是遍历操作，太慢了！
我们要面对十万级并发！（其实并没有）
必须优化！
然后，他闭关三天，重写了整个模块。
02 当“艺术代码”出现在 Code Review 屏幕上
Review 那天，我们全组沉默了。
屏幕上出现的是这样一段代码：
// 全程位运算，没有任何注释
const P = { r: 1, w: 2, e: 4, d: 8 };
const _c = (u, p) => (u & p) === p;
// 位移掩码生成权限
const _m = (l) => l.reduce((a, c) => a | (P[c] || 0), 0);
// 像不像一段乱码？
const chk = (u, r) => _c(_m(u.r), P[r]);
我鼓起勇气问了一句：
阿K，这个 _c 和 _m 是啥意思？
能不能加个注释？
阿K 振振有词：
好的代码不需要注释！
位运算是 CPU 执行最快的操作！
这是对性能的尊重，是艺术！
我：
……这是对同事的不尊重吧。
在一个根本没有性能瓶颈的后台系统里，
他为了肉眼不可见的 0.0001ms，
制造了一颗定时炸弹。
03 真正崩溃的那一天
两个月后，业务方提了个新需求：
支持「反向排除权限」，
权限字段从数字改成字符串数组。
偏偏那天，阿K 去年假了，手机关机。
任务落到了刚入职的实习生小李身上。
小李打开 permission.js，
看到满屏的 >> 、 & 、 | 和单字母变量名。
他试着改了一行。
结果是：
- 管理员突然没权限
- 实习生反而能删库
改哪里炸哪里。
“这代码有毒吧……”
小李在第 10 次失败后，差点哭出来
更致命的是：
- 位运算逻辑注入了全局原型链
- 权限模块和其他模块高度耦合
- 没人敢动，没人敢删
一个本该半天搞定的需求，
硬生生拖了一周。
最终，业务投诉直接捅到了 CTO 那。
CTO 看完代码，沉默了三分钟，只问了一句：
写这玩意儿的人，是觉得以后都不用维护了吗？
阿K 回来后很不服。
他甩出 Chrome Profiler 截图：
看！比你们的写法快了 40% ！
但他忽略了一条软件工程铁律：
代码价值 =（功能 + 可维护性）/ 复杂度
以及那句老到掉牙、却永远正确的话：
过早优化是万恶之源。
04 真正“高级”的写法，反而很朴素
后来，我们把那坨代码全部推倒重写。
1️⃣ 权限定义（语义清晰）
export enum Permission {
READ = 'read',
WRITE = 'write',
EDIT = 'edit',
DELETE = 'delete',
}
2️⃣ 用户模型
export interface User {
id: string;
permissions: Permission[];
}
3️⃣ 核心权限校验
export function hasPermission(
user: User,
required: Permission
): boolean {
return user.permissions.includes(required);
}
4️⃣ 批量校验
export function hasAllPermissions(
user: User,
required: Permission[]
): boolean {
return required.every(p => user.permissions.includes(p));
}
export function hasAnyPermission(
user: User,
required: Permission[]
): boolean {
return required.some(p => user.permissions.includes(p));
}
没有黑魔法，没有炫技。
但，任何一个新同事，5 分钟就能看懂并修改。
05 总结
这件事我学到的 3 个血泪教训
1. 代码是写给人看的
如果一段代码：
- 只有你现在能看懂 → 垃圾代码
- 连你一个月后都看不懂 → 有害代码
2. 不要在非瓶颈处炫技
页面慢是 DOM 太多，
你却去优化 for 循环
那叫隔靴搔痒。
3. 可读性 > 巧技
简单的逻辑，
是对同事最大的善意。
阿K 离职时，还是觉得自己怀才不遇，
觉得公司配不上他的技术 。
我祝他前程似锦。
但我更希望看到这篇文章的你，
在敲下一段只有你自己能看懂的“神级代码”前，停下来想一想：
如果我明天离职了，
接手的人会不会在工位上骂娘？
毕竟
我们不想让亲妈都不认识代码，
更不想让同事天天骂娘。
有效的 CodeReview 是保障代码质量与团队协作的关键。这个故事也提醒我们，在追求极致性能之前，优先考虑代码的可读性与可维护性，才是符合现代 前端工程化 实践的明智之举。关于技术成长的更多思考与实践，欢迎来 云栈社区 交流探讨。
发表于 昨天 03:25
|
查看: 5|
回复: 0
