代码洁癖不是病，但拖慢上线是真的

去年冬天某个周五晚上九点，我坐在工位上盯着屏幕发呆。窗外北京的夜色早已浓得化不开，办公室只剩我和隔壁组一个运维小哥还在加班。而我卡在了一个“诡异”的问题上：明明功能逻辑完全没问题，测试也过了，可就是死活不愿意合进主干——因为这段代码缩进用了两个空格，而项目规范是四个。

没错，我曾经是个重度代码洁癖患者。

我是腾讯微信小程序团队的一名客户端开发，三年前校招进来，从写第一个 wx.login 开始，到现在负责核心链路的性能优化。坐标北京，每天七点起床、八点开工，通勤一小时雷打不动。早起型选手的好处是能避开早高峰，坏处是……总比别人更早看到产品经理凌晨三点发的需求文档。

“完美主义”差点让我背锅

事情还得从去年双11说起。我们团队临时接到任务：紧急支持一个大促活动的小程序页面，要求三天内上线。时间紧、任务重，后端接口还没完全定稿，前端就得先搭骨架。

我接手的是首屏加载模块。为了“优雅”，我坚持要用最新封装的 hooks + TypeScript 严格类型校验，连注释格式都要对齐。结果呢？两天过去了，页面连基础渲染都没跑通。而隔壁老王——一个看着吊儿郎当但从不掉链子的老兵——用最朴素的 setData + 原生 JS，当天下午就把 demo 跑起来了。

更扎心的是，他在群里甩了句：“兄弟，用户不关心你代码多漂亮，他们只关心能不能三秒内抢到券。”

那一刻我愣住了。想起上周刚被 leader 拍肩膀：“你这代码写得是挺干净，但迭代速度跟不上业务节奏啊。” 当时我还嘴硬说“质量优先”，现在看，不过是自我感动罢了。

从“自嗨”到“交付”：我的转变之路

真正让我醒悟的，是一次线上事故。

某个版本里，我重构了一个公用组件，把所有冗余逻辑删得干干净净，变量命名也统一成 camelCase，还加了详细的 JSDoc。自测完美，提测顺利，上线当晚……崩了。

报错信息是：Cannot read property 'user' of undefined。
原因？我把一个“看似没用”的兜底判断给删了——那行代码其实是为了解决某个老旧机型兼容问题，而测试机都是新 iPhone。

回滚、道歉、复盘。leader 没骂我，只问了一句：“你觉得‘干净’和‘可靠’，哪个更重要？”

那晚回家地铁上，我想明白了：代码不是艺术品，是工具。它的第一使命是解决问题、支撑业务，其次才是可读可维护。过度追求形式上的“洁癖”，反而会掩盖真实的风险。

实战：如何在快与稳之间找平衡？

后来我开始调整策略，不再一味追求“零瑕疵”，而是建立一套分层标准：

场景	代码标准	工具/方法
核心链路（如支付、登录）	高可读性 + 单元测试覆盖 ≥80%	ESLint + Jest + 类型强校验
快速试错型活动页	功能正确即可，允许临时 hack	简化 lint 规则，注释标明 TODO
公共组件库	极致规范 + 文档齐全	Storybook + API diff 检查

比如现在做性能优化，我不再执着于“一行代码都不能多”，而是用数据说话。上周刚用 performance.measure 对比了两种写法：

// 写法A：极致精简
const data = res.data?.list || [];

// 写法B：带日志兜底
const rawData = res?.data;
if (!rawData) {
  reportError('missing data in response');
  return [];
}
const list = rawData.list || [];

虽然 B 看起来“啰嗦”，但线上错误率下降了 40%，而且排查问题快了一倍。有时候，多出来的几行代码，恰恰是最值钱的。

善用外力：别跟自己死磕

我也开始学会“借力”。比如最近团队引入了 通义千问 的代码审查插件（别笑，真的香）。它能自动识别潜在的空指针、异步竞态，甚至建议更高效的数组操作方式。以前我要花半小时检查的边界 case，现在一键扫描搞定。

更重要的是，它不会judge你的代码“丑不丑”，只关心“会不会崩”。这种客观视角，恰恰治好了我的主观洁癖。

还有就是多跟测试同学聊。有一次我嫌弃某个 if 分支“理论上不可能走到”，想删掉。测试妹子直接甩我一份灰度日志：“看，昨天有 237 个用户触发了这个路径。” 我当场闭嘴。

给同样“纠结”的你几点建议

如果你也像曾经的我一样，在“写出完美代码”和“按时交付”之间反复横跳，不妨试试这些：

• 设定“容忍阈值”：比如非核心模块允许存在少量 TODO，但必须标注负责人和截止时间。
• 用自动化兜底：把风格检查交给 ESLint/Prettier，把可靠性交给单元测试，别靠肉眼盯。
• 接受“阶段性丑陋”：MVP 阶段的代码可以糙，但要有清晰的重构计划，别让它变成技术债雪球。
• 多问一句“用户感知吗？”：如果优化不影响体验，也许该优先做别的事。

写在最后

现在的我，依然会在深夜默默调整缩进，看到乱糟糟的 commit 记录还是会皱眉。但我不再让它阻碍交付，也不再把它当作衡量自己价值的标尺。

在微信小程序这种亿级用户的战场上，快、稳、准远比“看起来漂亮”重要得多。代码终会迭代、会被重写，但你在关键时刻扛住压力、解决问题的能力，才是真正的护城河。

对了，上周那个双11活动页，最终提前半天上线，首日 GMV 超预期 150%。我在庆功饭局上敬了老王一杯：“下次重构，我请你喝瑞幸。”

他笑着回：“别整那些花的，先把 bug 修了。”

你看，这才是真实的前端日常——没有完美代码，只有不断前行的我们。

---

注：本文提到的“通义千问”仅作为团队内部试点工具举例，不代表官方合作。前端开发不易，且写且珍惜。