代码洁癖：我是如何克服的
凌晨两点，咖啡杯底已经干了，但我的脑子还清醒得很——这大概是我一天中效率最高的时候。我合上 LeetCode 的题解页面（没错，又在刷题，毕竟跳槽不能光靠嘴说），转头看一眼 IDE 里一段刚重构完的支付对账服务逻辑，心里却有点空。
不是因为 Bug，也不是因为线上告警。恰恰相反，这段代码“干净”得有点过头了：变量命名一丝不苟、函数拆到不能再小、注释多到能出书、连空行间距都严格遵循团队规范。可问题是……它上线一周了，没人敢动。
为什么？因为太“洁癖”了。
我是某金融科技公司五年的后端老油条，主攻高并发交易系统和资金对账模块。我们这行，安全是底线，容错是本能，一行代码出问题可能就是百万级别的资损。所以，代码洁癖一度是我的护身符——甚至可以说是职业本能。但最近两年，尤其是去年双11期间那场“史诗级”线上事故之后，我才真正意识到：过度的代码洁癖，有时候比烂代码更危险。
洁癖的“原罪”：我以为的完美，其实是枷锁
先说说我当初有多“病入膏肓”。
- 函数超过 20 行？不行，必须拆。
- 变量名用
tmp或data？死刑。 - 注释没写清楚上下文？重写。
- 前端传了个字段叫
user_id，但数据库是userId？必须统一命名规范，哪怕要改十个接口！
听起来是不是很专业？但现实是——我们不是在写教科书，而是在跑业务。
记得去年 9 月，产品突然甩过来一个需求：“下周一上线跨境支付新通道，支持实时汇率换算”。时间紧、对接方文档烂得像草稿，前端同学急得在群里@我三次：“哥，接口能不能先给个草稿版？我们好联调啊！”
我回了一句：“等我写完单元测试和 Swagger 文档，明天上午发你。”
结果呢？前端等到周五下午才拿到接口，联调到半夜发现我为了“字段命名一致性”，把所有金额字段从 amount 改成了 transaction_amount_in_cents。前端当场崩溃：“大哥，我们 UI 都按 amount 绑定了，现在全要改？”
那一刻，我看着 Slack 上那个哭脸表情，突然意识到：我的洁癖，正在拖慢整个团队的节奏。
更致命的是双11那天。我们有个对账服务，为了“极致解耦”，我把核心逻辑拆成了五个微服务，每个服务只做一件事，输入输出校验严苛到连空字符串都要抛异常。结果呢？第三方银行回调超时 3 秒，整个链路雪崩，对账延迟两小时，风控直接拉群：“资损风险！立刻回滚！”
回滚完我盯着监控面板发呆：如果当初容忍一点“脏”，比如加个本地缓存兜底、允许字段宽松匹配、甚至临时绕过部分校验，可能根本不会触发级联故障。
转折点：从 Rust 学会“可控的不洁”
其实转变的契机，有点讽刺——是因为我想跳槽，开始学 Rust。
Rust 这门语言，表面看是“内存安全狂魔”，连空指针都不让你有。但深入之后你会发现，它其实非常务实：它允许你用 unsafe 块突破限制，只要你明确知道后果并承担风险。
这让我恍然大悟：代码质量不是非黑即白，而是风险与收益的权衡。
于是我开始重新思考自己的“洁癖准则”。以下是我总结的几个实战经验：
1. 区分“核心路径”和“边缘逻辑”
在金融系统里，资金划转、账户变动这些是核心路径，必须洁癖到极致——类型强校验、幂等设计、审计日志一个都不能少。
但像用户头像上传、活动 banner 展示这种边缘逻辑，真的需要写三层 DTO + 校验器 + 异常处理器吗？
现在我的做法是：核心路径用 Rust 思维（零容忍），边缘逻辑用 Go 思维（快速交付）。比如最近一个营销活动接口，我直接让前端传整个 JSON 对象进来，后端只做基础签名验证，内部用 map[string]interface{} 处理——省了三天开发时间，产品笑开了花。
2. 与前端达成“脏协议”
以前我总想强迫前端遵守我的命名规范。现在？我学会了“向下兼容”。
举个例子，我们现在约定：前端可以传任意字段名，但后端必须能自动映射到标准模型。为此我写了个轻量级的字段适配层：
// 请求体可能包含 user_id, userId, uid 等变体
type FlexibleUser struct {
UserID string `json:"user_id,omitempty" alias:"userId,uid"`
}
func (f *FlexibleUser) UnmarshalJSON(data []byte) error {
var raw map[string]interface{}
if err := json.Unmarshal(data, &raw); err != nil {
return err
}
// 自动匹配别名
for _, key := range []string{"user_id", "userId", "uid"} {
if val, ok := raw[key]; ok {
f.UserID = fmt.Sprintf("%v", val)
break
}
}
return nil
}
前端再也不用求着我改字段名了，而我也保住了核心模型的纯洁性。双赢。
3. 用自动化代替人工洁癖
我承认，有些洁癖是懒——懒得写测试，所以靠“代码漂亮”来获得安全感。
现在我反过来了：只要自动化覆盖到位，代码可以“脏”一点。
比如我们现在的 CI/CD 流程：
| 检查项 | 工具 | 容忍度 |
|---|---|---|
| 单元测试覆盖率 | go test + codecov | ≥85%（核心模块 ≥95%） |
| 静态安全扫描 | SonarQube | 高危漏洞 0 容忍 |
| 接口契约校验 | Pact | 必须通过 |
| 代码风格 | golangci-lint | 警告可忽略，错误必须修 |
只要这些红线守住，函数长一点？变量名缩写？随它去吧。上周五晚上加班改一个紧急补丁，我甚至写了段“意大利面条式”代码，但因为有完整的契约测试和集成测试兜底，我睡得比谁都香。
心态调整：洁癖的本质，是对失控的恐惧
说实话，放下洁癖最难的不是技术，是心理。
我曾经觉得，代码不干净 = 我不专业 = 我会被淘汰。尤其是在准备跳槽、刷题压力大的时候，这种焦虑会被放大。
但后来我想通了：真正的专业，不是写出教科书般的代码，而是在复杂约束下做出最优决策。
产品经理要快？好，边缘功能我快速交付。
运维要稳定？行，核心链路我加上熔断降级。
测试要覆盖？没问题，自动化测试我写到吐。
代码只是手段，业务价值才是目的。
现在我甚至开始欣赏一些“脏但有效”的代码。比如我们有个老系统，用 PHP 写的，全局变量满天飞，但跑了八年零重大事故。为什么？因为它的“脏”是有上下文、有边界、有兜底的脏，而不是无脑堆砌。
给 fellow 程序员的建议
如果你也跟我一样有代码洁癖，不妨试试这几个方法：
问自己：这个“洁癖”是为了谁？
如果是为了让自己心安，而不是提升系统可靠性或团队效率，那可能是 ego 在作祟。建立“风险分级”意识
把你的代码按资损风险、用户影响、修改频率分类，不同级别用不同标准。和前端坐在一起写一天代码
亲身体验他们被后端各种“规范”折磨的痛苦，你会立刻理解什么叫“协作成本”。允许自己写“临时方案”
但一定要打上// TODO: refactor before Q3这样的标记，并纳入技术债跟踪。记住：没有完美的代码，只有合适的代码
就像 Rust 的unsafe，关键不是能不能用，而是知不知道为什么用、什么时候收手。
凌晨三点，我提交了今天的最后一个 commit。这次的代码不算“干净”：有个函数 35 行，用了 res 作为变量名，注释只有一句“临时方案，下周重构”。
但我很安心。因为我知道，它跑在非核心路径上，有完整的监控告警，前端联调顺利，产品已经验收。
而且——我终于能在 6 点前睡觉了，明天还要刷两道 DP 题呢。
代码洁癖？戒了。但对系统的敬畏，一分没少。
毕竟，在金融科技这行，我们可以容忍脏代码，但绝不能容忍脏数据。
这才是真正的底线。
评论 0