在黑暗中独自编程
译/腊八粥
“代码异味”【注1】是描述人们在检查代码时立即看到设计之初导致的潜在问题。Martin Fowler 把它描述为“通 常是系统深层次问题的一种表象”。它经常和粘贴的代码、反模式、过度复杂等观念联系在一起。我个人喜欢如下表述：一个人很少需要审视代码，来了解其中可能 存在的问题。如今，关于怎样检测代码异味的文章不下数百篇。一些工具可以输出指标，让你知道哪些地方可以优化。你懂的……
今天我想讨论另一种代码异味：完全被唯一一个人设计和开发的代码，从来没有被其他人看到或评审过的代码，在黑暗中输出的代码差不多总是有种代码 味道。（开源明确地被排除在外了）。这不代表，它就是糟糕的代码，但是如果被其他人查看和讨论，代码常常可以被优化和接近完美。根据我这么多年做为软件开 发者的经验，即使这个规则可能存在一些特例，我个人还从来没有看到这个理论失败过。如果你正独自编码，那么你正在做着错误的事情。
在意识到你的代码不会被其他人看到时，大量的不去寻求捷径的自我约束就会消失。文档数量减少、规则不会被优化、重构可能不会去完成。或许你输出了可运行的代码，但是如果你诚实地问自己一个问题：“如果明天我的代码开源给数千个开发者，有需要修改的地方吗？”，然后你将加入一大把 TODO 清单。
另一方面，在其他人的“目光下”编程会带来正能量。当你为其他人而不是自己写代码时，你将更加小心。你将更加在意细节，比如你命名变量的方式。 你将确保逻辑和算法被实现了、且测试正确。你的代码对于任何人更易读懂。一旦你的代码公开给其他人分析，它就随着时间而提高。来自其他人的反馈让你成为更 加谦虚、出色的程序员。我相信，这是开源代码开发所带来的真理。
在大部分私营企业，为将来设计代码的通常有多个人。代码审查的优先级高于功能测试。每个人都懂得采取额外步骤的 ROI（投资回报率）。然而，总是由于时间紧张、由于自负、甚至更糟糕的是因为害怕被鄙视，代码最终充满了瑕疵，过河拆桥，最终被留在了软件里而没有看一眼。
虽然我有很多场合可以避免把代码放在大家眼前，但是我从来没有一个好的、充分理由来这样做。时间不够？害怕其他开发者说的话？懒惰？自负？我本 人多次产生过所有这些感情。征求和接受反馈是不容易的。碰到你认为不错、而其他人认为还有改善空间的情况，是比较受伤的。意识到你不得不投入更多时间来优 化你认为完成了的代码，也是不爽的。没有人喜欢被告知他自己错了。常常阻碍我们编写更优雅代码的，不是其他开发者，而是自负和自我评价。
你很可能在想：“噢耶，你说得很明显了：代码审查提高代码质量……云云”。是的，的确如此。但是开发者做起来却不是一件自然的事儿！我们开发者 大部分是原始人。我们喜欢独处的舒适性，我们需要经历并产生自己的舒适性。把我们的代码放在聚光灯下是不自然的。我有多少次听到和看到，被单独留下的开发 者以信任和自治的名义，开发和发布代码，等意识到他们写的代码是糟糕的、不稳定的、且倾向于一坨屎的时候，已经太晚了。就在数周前，我被一个势利之徒建立 的数据库结构绊住了，他在我们公司只呆了几个月。该数据库包含了一堆由 3 个字母组成的表，每个表有 20-30 个字段，而每个字段也是 3 个字母……没人知道字段里存储的是什么。由于这个开发者有着较高的资历，6 个月来没有和大家交流过。他留下的只是神秘、未优化和非逻辑的代码。他是错在了没有把代码展示给别人看吗？同事是错在没有要求吗？当一个团队不能肩并肩输 出高质量代码时，这更像是团队问题而非个人问题。开发者不应该觉得分享代码是被强制的。他们应该出于自愿，因为他们明白这能够给他/她自己的代码技巧和代 码本身带来显著的积极影响。
不要在黑暗中独自编程。谈论你的代码，写一些关于你的代码方面的东西。分享它，让你的同事去看看，一起探讨和批评。让每个人都参与到这个过程。 资历浅的开发者有机会批评老同事输出的代码时，将增加自信。他将从分析优秀代码中受益。“我已看透一切的”、高级开发者有机会以不同的视角看待问题，并获 得巨大收获。当有机会时，要花时间来审查你同事的代码。找到哪些可以做得更好，总结你看到的有价值的地方，讨论你发现的问题并给出建设性意见。
优美的代码从来不会出自黑暗，它总是从分析和批评的火焰中得到升华。
- 注1：程序开发领域，代码中的任何可能导致深层次问题的症状都可以叫做代码异味.通常，在对代码做简短的反馈迭代时，代码异味会暴露出一些深层次 的问题，这里的反馈迭代，是指以一种小范围的、可控的方式重构代码。基于这些暴露的问题，人们会进一步的检查设计和代码中是否还存在别的代码异味，然后再 做进一步的重构。该术语似乎由 Kent Beck 于 90 年代后期，在 WardsWiki 上首次使用。http://zh.wikipedia.org/wiki/%E4%BB%A3%E7%A0%81%E5%BC%82%E5%91%B3
— END —