代码洁癖：我是如何克服的

大家好，我是小林，一个刚拿到某大厂offer的应届生。目前坐标北京，租住在天通苑——没错，就是那个被戏称为“亚洲最大社区”的地方。每天早上挤13号线去西二旗上班，仿佛参加一场没有硝烟的早高峰战役。房租3500块，合租次卧，阳台只能晾三件衣服，但好歹离地铁站步行12分钟（实测，没打车）。

今天想和大家聊聊一件让我又爱又恨的事：代码洁癖。

---

一、凌晨三点，我删掉了自己写的1000行代码

时间回到去年十月的一个周五晚上。

那天，我正为实习转正答辩做最后冲刺。项目是一个基于区块链的供应链溯源Demo，用Go语言写的，前端是Vue。按理说，功能跑通了，UI也差不多了，应该安心准备PPT才对。

但我盯着自己的代码，越看越不对劲。

变量命名不统一：有的叫itemID，有的叫itemId；
函数注释有的写得像论文，有的干脆空着；
更别提那些重复的校验逻辑，像牛皮癣一样贴在各个模块里……

“这怎么能交上去？HR看了以为我们组没人懂SOLID原则！”我心里嘀咕。

于是，我干了一件现在想起来都想扇自己一巴掌的事——重写整个核心模块。

从晚上9点开始，我一边喝着第三罐红牛，一边把原本能跑的代码全删了，打算用“更优雅”的方式重构。凌晨两点，室友发来消息：“兄弟，你还没睡？明天不是要答辩吗？”
我回：“快了快了，就差一个接口。”

结果，凌晨三点，系统跑不通了。
区块不上链，哈希对不上，连本地测试都崩了。
而我的电脑电量只剩7%。

那一刻，我瘫在椅子上，看着满屏红色报错，心里只有一个念头：我是不是不适合写代码？

---

二、什么是“代码洁癖”？它真的好吗？

说实话，“代码洁癖”这个词听起来挺酷的，好像你是个追求极致的工匠。但在我身上，它更像是一种焦虑的投射。

我本科在一所普通双非院校，大三才真正接触工程开发。因为起点低，总觉得自己写的代码“不够格”，怕被人笑话。于是拼命模仿GitHub上那些star过万的项目：严格的命名规范、复杂的分层架构、炫酷的设计模式……哪怕只是一个简单的CRUD，我也要套三层抽象。

久而久之，我陷入了一个怪圈：宁愿花三天时间让代码“看起来漂亮”，也不愿花一天让它“跑起来稳定”。

有一次，带我的mentor老张（一个头发快掉光但代码稳如老狗的后端大佬）看我提交的PR，皱着眉头说：“小林啊，你这个DTO和VO分得挺细，但用户要的是功能上线，不是UML图。”

我嘴上答应，心里却嘀咕：“你不就是觉得我太啰嗦嘛，但整洁的代码才是专业的体现！”

直到那次答辩前夜的崩溃，我才意识到：过度追求形式上的“洁癖”，反而成了生产力的枷锁。

---

三、转折点：一次“脏代码”救了我的命

转机出现在今年三月。

当时我参与公司内部一个紧急需求：对接某联盟链的智能合约，需要在48小时内完成一个数据同步服务。时间紧、任务重，而且合约接口文档写得像天书。

我第一反应还是想先搭个“完美”的项目结构：DDD分层、统一异常处理、全局日志追踪……结果刚建完目录，PM就冲进会议室喊：“兄弟们，客户那边催了，今晚必须出测试版！”

没办法，我咬咬牙，决定“先跑起来再说”。

于是，我干了这辈子最“不体面”的事：

• 所有逻辑塞在一个main.go文件里
• 变量名直接用a, b, temp
• 错误处理？try-catch一把梭，不行就log.Fatal
• 区块链交易失败？重试三次，再失败就邮件告警（其实是发到我自己微信）

代码丑得我自己都不忍直视。但神奇的是——它居然跑通了！

第二天早上，客户反馈数据同步成功，还夸我们响应快。组长拍拍我肩膀：“干得不错，虽然代码像泡面桶，但解决问题了。”

那一刻，我突然悟了：代码的第一使命是解决问题，不是取悦审美。

---

四、开发心得：在“能跑”和“好看”之间找平衡

从那以后，我开始调整自己的开发哲学。结合这段时间在大厂实习+转正的经历，总结了几条“反洁癖”心得：

1. 区分“可维护性”和“强迫症”

整洁的代码确实重要，但前提是团队共识+业务阶段匹配。如果你在一个MVP（最小可行产品）阶段，还在纠结要不要用策略模式替代if-else，那大概率是在浪费时间。

我现在写代码，会先问自己三个问题：

• 这段代码三个月后还会有人改吗？
• 如果不重构，会导致线上事故吗？
• 重构的时间成本 vs 业务收益，划算吗？

如果答案都是“否”，那就先让它跑着。

2. 区块链项目尤其不能“洁癖”

说到区块链，很多人觉得这玩意儿高大上，代码必须滴水不漏。但现实是：链上调试成本极高，gas费烧钱如流水，合约一旦部署就不能改。

所以在做链下服务（off-chain service）时，我的策略是：快速验证逻辑 → 单元测试覆盖 → 再考虑抽象。
比如最近做的一个NFT铸造服务，我先把签名、上链、回调全写在一个函数里，跑通后再拆成Signer, ChainClient, EventHandler三个组件。这样既保证效率，又不至于后期无法维护。

3. 学会“战略性脏代码”

有些地方，脏一点反而更高效。比如：

• 临时脚本（一次性数据迁移）
• Mock服务（用于联调）
• 紧急热修复（hotfix）

这些代码的生命期很短，没必要套上华丽外衣。我甚至会在注释里写：“此处很脏，勿学！——by 小林，2024/06/15”。

4. 接受“不完美”的自己

最根本的转变，其实是心态。我不再因为代码不够“优雅”而自我攻击。毕竟，软件工程是妥协的艺术，不是数学证明。

上周五晚上，我又加班到十点。这次不是因为重构，而是帮同事排查一个奇怪的区块同步延迟问题。解决后，我关掉电脑，走在天通苑回家的路上，路灯昏黄，晚风微凉。

突然觉得，代码就像生活——不需要每一块砖都打磨得锃亮，只要房子能遮风挡雨，住得舒服，就够了。

---

五、给和我一样的“洁癖新人”的建议

如果你也和我一样，曾经（或正在）被代码洁癖折磨，不妨试试这几招：

• 设定“洁癖阈值”：比如只对核心模块严格要求，边缘功能放宽松。
• 用工具代替手工：ESLint、gofmt、prettier这些自动化工具能解决80%的格式问题，省下精力思考业务。
• 多看生产代码：别只盯着开源项目的README，去看看它们issue区和历史commit，你会发现很多“脏代码”都是业务逼出来的。
• 和前辈聊真实场景：我在转正后和老张深聊过一次，他说：“我十年前写的代码，现在看都想吐，但它撑起了公司第一个百万用户产品。”

最重要的是：别让完美主义成为你交付的敌人。

---

六、尾声：从天通苑到未来

如今，我的月薪从实习期的15k涨到了22k（税前，别羡慕，北京房租贵啊）。虽然还在天通苑住着，但心态变了。

我不再半夜因为一个变量命名辗转反侧，也不再因为PR被comment“这里可以优化”就焦虑到吃不下饭。

我开始享受“解决问题”的快感，而不是“写出完美代码”的幻觉。

代码如人，不必无瑕，但求有用。

共勉。

—— 小林，于北京天通苑，2024年6月