代码洁癖：我是如何克服的
去年十月的一个深夜，天通苑出租屋的窗外下着小雨，我盯着屏幕上一段“脏兮兮”的 Java 后端代码，手指在键盘上敲了又删、删了又敲，整整三个小时没动一行有效逻辑。那会儿是凌晨一点半，老婆已经睡了，我还在为要不要重构一个明明能跑但缩进混乱、命名随意的旧模块而纠结。
我当时的状态，用圈内话说就是：“重度代码洁癖晚期”。不是不能改，而是看到 userService.getUserInfo() 被写成 uSvc.gUI() 就生理不适；看到 if 嵌套超过三层就坐立不安；看到没有单元测试覆盖的核心接口，心里就像有只蚂蚁在爬。
那会儿我在一家中型互联网公司做后端开发，月薪18k，房租3500（对，天通苑的老破小），每天地铁来回两个半小时。表面看还行，但内心其实很焦虑——因为我发现自己的“洁癖”正在拖慢交付速度，甚至影响团队节奏。
曾经的我：追求完美，却寸步难行
记得有一次，产品临时加了个需求，要在用户登录流程里插入一个风控校验。其实逻辑很简单：调个外部服务，判断是否高风险，是就拦住，不是就放行。正常人一小时搞定，但我花了整整两天。
为什么？因为那段登录逻辑原本就没写好——变量命名模糊、异常处理缺失、日志埋点混乱。我越看越难受，干脆决定“顺手重构一下”。结果越改越多，最后连认证中心的缓存策略都重写了。上线前 Code Review，组长直接把我叫过去：
“兄弟，你这活儿干得漂亮，但需求明天就要上线，你搞了两天……现在测试还没开始跑。”
那一刻我突然意识到：我的“洁癖”，已经从一种对质量的追求，变成了一种逃避现实的完美主义。
更糟的是，在上一家大厂裁员潮中，我亲眼看到一个技术极强但交付极慢的同事被裁掉。HR私下跟我说：“他代码写得确实干净，但业务等不起。” 那句话像根刺，扎在我心里很久。
转折点：从“理想主义”到“实用主义”
真正让我转变的，是一次紧急故障。
今年三月，我们线上支付回调接口突然大量超时。我作为值班后端，第一时间排查。日志显示问题出在一个三年前写的订单状态更新逻辑里——那段代码简直是我职业生涯见过最乱的：全局变量滥用、事务边界模糊、还有几处硬编码的魔法数字。
按我以前的性格，肯定要先重构再修复。但那次不行。用户付了钱，订单卡在“待支付”，客服电话被打爆。我只能硬着头皮在“屎山”里打补丁。
那天晚上我熬到凌晨四点，用最丑的方式修好了 bug：加了个 try-catch 包裹、硬塞了几行日志、临时绕过了某个失败分支。代码提交时，我自己都脸红——这要是放以前，我绝不会让它进主干。
但神奇的是，系统稳了。第二天用户投诉归零。老板在晨会上说：“感谢XX同学快速响应，保住了用户体验。”
那一刻我忽然明白：代码不是艺术品，而是解决问题的工具。用户的支付成功，比我的审美满足重要一万倍。
工具思维：用工程手段管理“洁癖”
从此以后，我不再试图靠意志力压制洁癖，而是把它“外包”给工具和流程。
比如，我现在在团队推行了一套自动化检查机制：
- 提交前用 Checkstyle 强制命名规范
- CI 流程里集成 SonarQube，复杂度超标直接拒绝合并
- 核心模块必须有 JaCoCo 覆盖率门禁（不低于70%）
这些工具成了我的“洁癖代理人”。我不再需要肉眼盯着每一行缩进，因为机器会替我守底线。而我可以把精力放在真正重要的事情上：架构设计、性能优化、业务理解。
我还学会了“分层容忍”：
- 核心交易链路：必须干净、可测、可追溯，这里我依然严苛
- 边缘功能或临时方案：允许“战术性脏代码”，但必须打上
// TODO: refactor by 2024-Q3标签，并记录在技术债看板里
上周五晚上，我又遇到一个类似登录风控的需求。这次我怎么做？
先花15分钟写了个最小可行方案，当天下午就提测。然后在 Jira 里建了个技术债任务：“【TechDebt】重构风控接入层”，排进下个迭代。
既保证了交付，又没放弃长期质量——这才是成年人的代码观。
洁癖不是病，但得治
回过头看，我的代码洁癖其实源于一种深层不安全感：害怕别人觉得我技术差，害怕线上出事背锅，害怕自己不够“专业”。
但在职场六年，从被裁到跳槽涨薪到22k，再到如今带两个新人，我越来越清楚：真正的专业，不是写出教科书般的代码，而是在约束条件下做出最优权衡。
有时候，一段能跑的“烂代码”，比一个永远写不完的“完美设计”更有价值。毕竟，我们不是在 GitHub 上写开源项目，而是在真实世界里交付业务价值。
现在的我，依然会在看到糟糕代码时皱眉，但不会再因此失眠。我会评估：这会影响稳定性吗？会增加维护成本吗？如果答案是否，那就先放过它。毕竟，我的时间很贵——时薪算下来快200块了，哪能天天跟命名较劲？
给同样有洁癖的你
如果你也像曾经的我一样，看到 if-else 嵌套就手痒，看到魔法数字就心慌，我想说：
- 接受“足够好”：软件是演进的，不是一蹴而就的。先让功能跑起来，再逐步优化。
- 善用工具：把重复的规范检查交给自动化，解放你的大脑去思考更复杂的问题。
- 区分场景：核心系统 vs 实验性功能，对待标准应该不同。
- 关注结果：用户是否满意？系统是否稳定？业务是否增长？这些才是终极指标。
前几天和老婆聊天，她说：“你最近脾气好多了，是不是工作顺了？”
我笑笑没说话。其实是我不再跟自己较劲了。
代码可以不完美，但人生可以更从容。
后记：
写这篇文章的时候，我刚搬进天通苑新租的房子——还是老小区，但朝南，阳光很好。房租涨到了3800，不过值得。
因为我知道，真正的“整洁”，不在代码里，而在心里。
评论 0