在黑暗中独自编程

jopen 9年前

在黑暗中独自编程

        英文原文:Coding Alone In The Dark

        译/腊八粥

        “代码异味”【注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 —