你的代码，就是你的节操

别再对着屎山叹气了

我们都经历过这样的时刻：接手一个老项目，打开 IDE，那一瞬间仿佛闻到了一股陈年的腐烂味道。函数有几千行，变量名叫 a、b、temp，逻辑像纠缠的兰州拉面一样令人绝望。

这时候，最容易脱口而出的一句话是：“这是历史遗留问题，我也没办法。”

历史原因，这四个字真是太好用了。它像一块巨大的遮羞布，瞬间掩盖了所有的混乱、懒惰和妥协。它让我们心安理得地在这座“屎山”上再拉一坨新的，然后告诉自己：“我只是在遵循‘现有的风格’。”

但这篇博客不是为了吐槽前人，而是为了拷问我们自己。

问：看见别人的错误却沉默，我们在怕什么？

当我们看到一行明显不合理的代码，看到一个会导致内存泄漏的写法，或者看到一个毫无必要的复杂逻辑时，如果我们选择视而不见，甚至照猫画虎地 Ctrl+C，那我们是什么？

我们是共犯。

为什么不反抗？

是因为害怕改动了会炸雷？是因为觉得“反正不是我写的，出了事不怪我”？还是因为那个“破窗效应”——既然窗户已经破了，多我这一块石头也无所谓？

如果你发现了错误却不反抗，你会慢慢变成一个技术官僚。你会开始擅长推诿，擅长写免责声明，却丧失了作为工程师最宝贵的能力——解决问题的能力。你以为你在明哲保身，其实你正在亲手埋葬自己的技术敏锐度。

雪崩时，没有一片雪花觉得自己无辜

波兰诗人斯坦尼斯洛·耶日·勒克（Stanisław Jerzy Lec）曾写下一句振聋发聩的话：

“雪崩时，没有一片雪花觉得自己有责任。” (No snowflake in an avalanche ever feels responsible.)

在技术债务引发的雪崩时，那次严重的线上故障、那个彻底无法维护不得不重构的模块、那次因为性能问题导致的客户流失发生时，我们每个人都是无辜的吗？

• 张三说：“我只是加了一个临时补丁，本来说好下周改的。”
• 李四说：“我看到那个函数很长，但我不敢动，我只是在里面塞了一行 if-else。”
• 王五说：“Code Review 的时候我太忙了，而且测试都过了，我就点了 Approve。”

看，每个人都只是做了一点点微不足道的妥协。

但正是这成千上万个微小的妥协，这无数次“算了，就这样吧”，最终汇聚成了压垮系统的万钧之力。

我们就是那一片片雪花。 当系统崩塌时，我们不能一脸无辜地站在废墟上说“这不关我的事”。每一次对低质量代码的纵容，都是在往山顶堆积最后那片致命的积雪。

问：如果是我的错误，为什么当初没人叫醒我？

让我们诚实一点。那些现在的“历史债务”，很有可能就是两年前的我们亲手写下的。

当时我为什么会写出那样的代码？

也许是因为赶进度，也许是因为那时候我真的不懂什么是设计模式。

但最可怕的是，当时竟然没有人阻止我。

那时候的代码评审（Code Review）在哪里？是不是大家都只是在走过场，点个 Approve 就完事了？是不是因为大家都在维护一种虚假的“表面和谐”，不好意思指出同事代码里的“愚蠢”？

如果当时有人狠狠地在评论区打出一行：“这段代码是垃圾，重写。” 我当时可能会脸红，可能会生气，但今天的我，会对他感激涕零。

没有痛苦的反馈，就没有觉醒。 在温水煮青蛙的锅里，我们都以为自己在泡温泉，直到水沸腾。

你的代码，就是你的节操

在这个行业里，我们没有什么实体产品能拿在手里把玩。我们留下的，只有一行行代码。

代码就是你的名片，甚至可以说是你的节操。

• 写出清晰、健壮、优雅的代码，是你对自己职业尊严的守护。
• 写出混乱、脆弱、晦涩的代码，就是把自己的节操丢在地上，还上去踩了两脚。

你可能会说：“老板只看结果，不看代码。”

是的，短期内也许如此。但长期来看，总是把节操丢在地上的工程师，最终会被自己的垃圾绊倒。 你会发现你修 Bug 的时间比写代码的时间还长，你会发现你的系统稍微一动就崩，你会发现你再也无法在这个行业里挺直腰杆。

你构建的一起，最终也构建了你

我非常喜欢这样一种观点：你所构建的一切，最终反过来也在构建你自己。

如果你习惯了构建“一次性垃圾”，你就会变成一个“一次性工程师”。

如果你坚持构建“艺术品”，哪怕只是一个简单的工具类，这种追求卓越的习惯也会刻进你的骨髓，让你变成一个卓越的人。

特蕾莎修女（Mother Teresa）有一首著名的诗（或者说是箴言），我想它同样适用于我们工程师：

The goods you build will be used by people who may destroy them. Build anyway.

你耗费数年所建设的，可能毁于一旦。 不管怎样，总是要建设。

也许我们现在写的系统，三年后就会被重构，五年后就会下线。我们精心设计的架构，可能会被后来者改得面目全非。

那又怎样？

摧毁它，是时间的事，是别人的事，甚至是上帝的事。

但把事情做对，那是我的事。

我们在编写高质量代码的过程中，磨练的是心性，提升的是认知，沉淀的是作为创造者的骄傲。这种内功，是谁也夺不走的。

附录：关于代码质量的“道、法、术”

认知（道）建立了，行动（法、术）自然水到渠成。以下是一些供大家参考的原则与方法，我们不搞教条主义，但我们需要底线。

1. 核心原则 (Principles)

• 像教孩子一样约束自己： 永远保持离开时的露营地比你发现时更干净。修改一个文件时，顺手清理一下旁边的杂草。
• 停止做“雪花”： 不做系统崩溃的推手。如果你不知道怎么写更好，请去问，请去学，但不要糊弄。
• DRY (Don’t Repeat Yourself)： 复制粘贴是万恶之源。
• KISS (Keep It Simple, Stupid)： 炫技是幼稚的表现，简单才是我们要追求的境界。

2. 流程 (Process)

• 认真对待 Code Review： 任何代码未经 Review 禁止合并。Review 不是为了挑刺，而是为了学习和兜底。
• 技术债登记： 如果因为紧急情况不得不写烂代码，请必须建立一个 Ticket 记录下来，承诺归还日期。

3. 方法与工具 (Methods & Tools)

• 自动化大于文档： 能用 Linter (ESLint, CheckStyle, SonarQube) 解决的，就不要用嘴说。
• 测试驱动： 没有单元测试的代码，就是裸奔。反复让 AI 帮你重新生成 Pass 的测试，其实也等于没有测试。

结语

我们要去的地方，不一定是星辰大海，但肯定不是垃圾填埋场。

从今天的下一次 Commit 开始，试着把地上的节操捡起来，擦一擦。

做正确的事，即使没人看着。