大家好，我是李司凌！
这是发生在上周的事情，我们团队的 “炫技达人” 艾庄碧离职了。
我说句老实话，艾庄碧的前端功底不差：他能徒手写防抖节流，对 React Fiber 架构有自己的见解，甚至能自己封装 Promise 工具库。但最终，领导还是忍痛让他走了 —— 理由居然是：你的代码，没人敢改。
为了追求 “代码简洁”（其实是炫技），牺牲可读性和可维护性，在前端领域里，真的值得吗？
这事的开端：一个简单的表单状态判断
我们有个用户注册表单，需要根据三个条件展示不同提示：
- 未填写时显示 “请完善信息”
- 填写不完整时显示 “还有 X 项未完成”
- 全部填写时显示 “可提交”
- 格式错误时显示对应错误提示
正常前端人（比如我）会这么写，逻辑清晰，一眼看透：
// 表单提示展示逻辑
const getFormTip = (formData, errorMsg) => {
// 存在格式错误，优先显示错误
if (errorMsg) {
return errorMsg;
}
// 统计未填写字段
const unCompleted = Object.values(formData).filter(item => !item).length;
// 全部未填写
if (unCompleted === Object.keys(formData).length) {
return "请完善信息";
}
// 部分未填写
if (unCompleted > 0) {
return `还有${unCompleted}项未完成`;
}
// 全部填写完成
return "可提交";
};
但艾庄碧看到后，眉头一皱：“太啰嗦了！这么简单的逻辑要写十几行？”
他大手一挥，重构后的代码变成了这样（Code Review现场直击）：
// 艾庄碧的"精简版"：一行三元嵌套搞定
const getFormTip = (f,e)=>e||(Object.values(f).filter(i=>!i).length===Object.keys(f).length?"请完善信息":Object.values(f).filter(i=>!i).length>0?`还有${Object.values(f).filter(i=>!i).length}项未完成`:"可提交");
那天我们在做代码走读时，大家瞬间懵了个圈……
我就问他：“艾庄碧，这嵌套也太多了，能不能加个注释？变量 f 和 e 是啥意思啊？”
他却回答：“司凌哥，好的代码不需要注释！三元表达式比 if-else 执行快，而且一行搞定多简洁？这是前端工程师的代码美学呢哈哈哈哈？”
我：..... (nmd)
你要晓得，这个表单只是个普通的后台注册页啊，我们后台用户看板显示日均访问量都不足 1000，完全不存在性能瓶颈。他为了 “一行代码” 的炫技，制造了第一个维护陷阱。
屎山崩塌的那天：需求变更 + 艾庄碧请假
灾难发生在一个月后。
产品经理突然提需求：“表单要加一个‘草稿保存’状态，未提交但已保存的话，提示‘草稿已保存，可继续编辑’”。
巧的是，艾庄碧那天又请假去玩儿去了，一直联系不上。
这个任务呢，就只有让刚来不久的前端新人武志毅上。
武志毅打开表单组件一看，一行超长的三元表达式特别显眼，当场石化了 —— 一行代码上全是问号、引号和大括号，连个换行都没有。武志毅在原有逻辑上添加新状态值，结果改一次崩一次：
- 改完后，草稿状态和未填写状态提示重叠了
- 再改，格式错误提示不显示了
- 最后改，直接报语法错误，整个表单都渲染不出来了
武志毅越改越懵，最后在群里把这个问题抛了出来：“谁能看懂艾庄碧写的这段代码啊？woc”
我们几个老前端围过来，花了估计有 10 分钟才理清三元嵌套的逻辑 —— 因为它没有变量命名、没有换行、没有注释什么的，光拆解结构就费了半天劲。这就算了，更坑的是，艾庄碧为了 “精简”，把 formData 简写为 f，errorMsg 简写为 e，连未完成字段的统计都重复写了三次，没有抽成变量。
最后，我们实在不敢在原有代码上改了，只能重构。原本 1 小时能搞定的需求，硬生生折腾了一下午。产品经理催得急，领导也被惊动了。
领导看完那段代码，只说了一句：“这写的是啥？以后他离职了，这代码谁来维护？”
前端圈的 “炫技陷阱”：这些坑你一定踩过
艾庄碧回来后，还觉得委屈：“我那代码多简洁啊，执行效率又高，你们就是不习惯而已。”
但他忘了，前端开发的核心是 “工程化”，不是 “个人炫技”。在前端领域，这样的 “炫技陷阱” 比比皆是：
- 无意义的单行代码：把几十行逻辑压缩成一行，用各种嵌套和简写，可读性为 0
- 过度使用黑魔法：为了省几行代码，用 eval、with、原型链污染等黑科技
- 变量命名极简主义：a、b、f、e、x 这种变量名随处可见，三个月后自己都忘了啥意思
- 拒绝注释和文档：觉得 “好代码不需要注释”，但忘了别人不一定懂你的思路
- 过早优化：在非瓶颈处优化，比如给简单表单加虚拟列表，给普通按钮加防抖（其实根本不需要）
前端领域有个共识：代码是写给人看的，顺便让机器执行。尤其是前端项目迭代快、需求变更频繁，可读性和可维护性远比 “炫技式精简” 重要。
V8 引擎的优化已经足够强大，现代构建工具（Webpack、Vite）也会自动压缩代码、优化性能。你为了 “执行快 0.001 毫秒” 写的晦涩代码，带来的维护成本可能是 10 倍、100 倍。
好的前端代码，应该是什么样的？
后来，我们把艾庄碧的表单逻辑重写了，不仅支持了新需求，还让所有人都能看懂：
// 1. 变量命名语义化，拒绝简写
/**
* 获取表单提示文本
* @param {Object} formData - 表单数据
* @param {string|null} errorMsg - 错误提示信息
* @param {boolean} isDraftSaved - 是否已保存为草稿
* @returns {string} 提示文本
*/
const getFormTip = (formData, errorMsg, isDraftSaved) => {
// 优先显示错误提示
if (errorMsg) {
return errorMsg;
}
// 统计未完成字段（抽成变量，避免重复计算）
const unCompletedCount = Object.values(formData).filter(item => !item).length;
const totalFieldCount = Object.keys(formData).length;
// 草稿已保存状态
if (isDraftSaved) {
return "草稿已保存，可继续编辑";
}
// 全部未填写
if (unCompletedCount === totalFieldCount) {
return "请完善信息";
}
// 部分未填写
if (unCompletedCount > 0) {
return `还有${unCompletedCount}项未完成`;
}
// 全部填写完成
return "可提交";
};
// 组件中使用：参数清晰，一目了然
<span className="form-tip">
{getFormTip(formData, errorMsg, isDraftSaved)}
</span>
这段代码没有任何 “炫技操作”，但胜在：
- 变量命名语义化，不用猜
- 逻辑拆分清晰，有注释说明
- 可扩展性强，加新状态只需加一个 if
- 新手接手 5 分钟就能懂
其实，前端开发的本质是 “解决问题”，不是 “展示技术”。一段好的前端代码，应该具备这三个特质：
- 可读性第一：别人能快速看懂你的逻辑
- 可维护性第二：别人能安全地修改你的代码
- 性能优化第三：只在有明确瓶颈时才优化，且优化后要保留可读性
最后想说的话
艾庄碧走的时候，还在抱怨公司 “不懂技术”“不尊重代码美学”。但他忘了，前端是团队协作的工作，你的代码不是个人作品，而是团队资产。
我们写代码，不是为了让别人觉得 “哇，你好厉害”，而是为了让项目能稳定迭代、让同事能高效协作。
或许你也写过这样的 “炫技代码”：用复杂的正则替换简单的字符串处理，用嵌套的高阶组件替换普通组件，用各种简写把代码压缩到极致……
下次写代码的时候，不妨停下来想一想：
- 如果明天我离职了，接手的人能看懂吗？
- 如果需求变更了，这段代码能轻松修改吗？
- 这个 “优化” 或 “炫技”，真的有必要吗？
前端圈不缺技术大牛，缺的是能写出 “让人舒服的代码” 的工程师。毕竟，没人想对着满屏的 “天书代码” 骂娘，也没人想让自己的代码变成团队的 “维护噩梦”。
希望我们都能做一个 “有温度的前端工程师” —— 用清晰的逻辑、语义化的命名、友好的注释，善待自己，也善待同事。
如果你觉得内容有用，欢迎 点赞 + 关注 + 转发 给身边的前端同学，让更多人避开这种“炫技”行为～
更多前端面试干货、学习资料，以及进群交流的机会，记得关注前端小皇帝，我们一起成长，拿到高薪工作机会！
