代码洁癖害我熬到凌晨三点，直到我学会了“脏活哲学”
上周五凌晨2:17，我瘫在工位上，盯着 VSCode 里一段被自己删了又写、写了又删的 JavaScript 代码，终于意识到：我的代码洁癖快把我逼疯了。
我是杭州某大厂游戏服务端开发，日常写 Node.js + TypeScript，但前端那摊子破事也得搭把手。VSCode 里装了 Prettier、ESLint、EditorConfig、Bracket Pair Colorizer、Todo Tree……插件多到启动要十秒，连 Tab 键缩进几个空格都要纠结半天。以前觉得这是“专业”，现在只觉得是“自虐”。
事情起源于一个看似简单的需求：给游戏大厅加个动态资源加载模块。产品经理说：“用户进大厅时，别一次性把所有皮肤、特效、背景音乐都拉下来，太卡了，按需加载。”听起来很合理，对吧？但当我真正开始写代码时，洁癖犯了。
“优雅”害死人
一开始，我非要搞个“完美”的资源管理器。抽象出 ResourceLoader、ResourceCache、ResourceManifest 三个类；用 Proxy 拦截属性访问；写了个 DSL 描述资源依赖关系；甚至考虑引入 RxJS 做响应式流控制。代码结构漂亮得像教科书，注释比代码还多。
class ElegantResourceLoader {
constructor(manifest) {
this.manifest = new Proxy(manifest, {
get(target, prop) {
if (!target[prop]) {
throw new Error(`Resource ${prop} not declared in manifest`);
}
return target[prop];
}
});
this.cache = new LRUCache({ max: 50 });
}
async load(name) {
if (this.cache.has(name)) return this.cache.get(name);
const url = this.manifest[name];
const res = await fetch(url);
const blob = await res.blob();
this.cache.set(name, blob);
return blob;
}
}
看起来是不是很“干净”？但上线前压测直接翻车——内存爆了。
为啥？因为那个“优雅”的 Proxy 在每次访问 manifest 时都做校验，而游戏大厅每帧要查几十个资源状态。再加上 LRU Cache 的引用没及时释放，Node.js 的 V8 堆内存一路飙到 4GB。运维半夜打电话骂我：“你这代码是拿金子写的？服务器快烧了！”
当时真的想砸电脑。不是因为 Bug，而是因为我为了“干净”浪费了三天时间，结果还不如隔壁实习生直接写个 if-else 来得高效。
脏活哲学：能跑就行，先上线
被领导叫去谈话，原话是：“你代码是写给机器跑的，不是写给 GitHub Star 看的。” 这句话扎心但真实。
于是，我彻底放飞自我。删掉所有“设计模式”，砍掉 Proxy，Cache 用最简单的 Map，错误处理全靠 try-catch 包裹，甚至连变量名都懒得改（res1, tmpData 随便用）。最终版本长这样：
const resourceCache = new Map();
async function loadResource(name) {
if (resourceCache.has(name)) {
return resourceCache.get(name);
}
try {
const url = RESOURCE_MAP[name]; // 全局常量，别问，问就是快
const res = await fetch(url);
const data = await res.arrayBuffer();
resourceCache.set(name, data);
return data;
} catch (e) {
console.error(`Failed to load ${name}:`, e);
return null; // 别抛异常，让 UI 自己兜底
}
}
丑吗？丑。但它快、稳、省内存。双11预演期间，QPS 从 800 干到 3500，内存稳定在 800MB，GC 压力极低。
更重要的是——我周五晚上十点就下班了。
洁癖 vs. 资源：程序员的永恒矛盾
回头想想，我的问题不在追求整洁，而在混淆了“代码整洁”和“系统效率”。
在游戏服务端，资源（CPU、内存、带宽）永远比代码可读性更稀缺。你写一百行“优雅”的 JavaScript，不如一行 buffer.slice(0, 1024) 来得实在。尤其是在杭州这种卷成麻花的环境，阿里网易隔壁天天抢人，项目节奏快到飞起，哪有时间给你重构三遍？
我整理了一个对比表，记录了“洁癖写法”和“脏活写法”在真实场景下的差异：
| 维度 | 洁癖写法 | 脏活写法 |
|---|---|---|
| 开发时间 | 3天 | 6小时 |
| 内存占用 | 4.2 GB | 780 MB |
| 错误恢复 | 抛异常，服务中断 | 返回 null，前端降级 |
| 可维护性 | 理论上高，实际没人敢动 | 谁都能改，反正逻辑直白 |
| 我的睡眠时间 | 凌晨3点 | 晚上10点 |
看到最后一条，你就懂了。
如何“健康地”克服代码洁癖？
我不是说从此不写 clean code。而是学会在正确的地方妥协。
- 核心逻辑保持清晰：比如资源加载的调度算法、状态同步机制，这些必须严谨。但外围胶水代码，能省则省。
- 性能敏感路径拒绝“优雅”：高频调用的函数，别用 Proxy、Reflect、Decorator，它们都有开销。JavaScript 的 JIT 优化喜欢简单直接的代码。
- 用工具代替人工洁癖：Prettier + ESLint 自动格式化，别手动调空格。你的精力应该花在架构设计上，而不是缩进对齐。
- 接受“暂时的脏”：上线前加个
// TODO: refactor this garbage注释，等流量平稳再重构。别让完美主义拖垮交付。
最后一点真心话
刚入行时，我也以为好程序员 = 代码像诗。后来在阿里实习，看 senior engineer 直接在生产日志里 grep ERROR 定位问题，才发现：真正的高手，是能让系统稳如老狗的人，不是写出最美代码的人。
现在我在 VSCode 里依然装了一堆插件，但学会了关掉“保存时自动格式化”——有些时候，脏代码就是生产力。
如果你也在为一行代码的命名纠结到凌晨，不妨问问自己：这段代码，是在消耗我的资源，还是在节省系统的资源？
答案清楚了，选择就简单了。
毕竟，明天还要早起改产品经理临时加的“小需求”呢。
评论 0