4dd9d09819dcb

随着万圣节越来越流行,我感觉有必要跟大家讨论一下一个在软件开发中非常普遍的问题:僵尸代码。几乎所有我接触过的代码库里都四散着很多小段的,甚至大片大片的被注释掉的代码。这就是僵尸代码。

// 目前禁用这项功能。Jimmy在写这段代码时肯定是喝醉了。

// 你可能以为这里发生了恐怖的代码凶手安…不,不,我只是把它们注释掉了…

为什么称它们为僵尸代码?你知道,僵尸不并不是真的死的。就像恐怕电影里告诉我们的,尽管僵尸看起来是死人,但它们仍有能力四处出没袭击我们。相同的道理,僵尸代码也是处于不生不死之间…

它们在伺机搞砸我们的工作。注释掉的代码还活着,它们就存在我们的代码库中。程序员在维护和重构代码时会和它们遭遇,通常是滚动屏幕时和它们擦肩而过,或是在进行关键词搜索时和它们撞个满怀。但这些代码也确实是死的,因为它们在软件产品中并不执行。因此,这些僵尸就应该被烧掉,立刻。

僵尸代码不死之躯

我认为,有两个原因导致了僵尸代码的肆虐:懒和害怕风险。懒程序员对代码有收藏癖。他们缺乏确信的勇气和清楚的认识去删除无用的代码,于是他们就把它们隐藏在注释里,期望有朝一日它们能复活来再次祸害人。代码需要经常的、有计划的删除,因为优秀的程序员都知道:代码就是债务。越少越好。当然,被注释掉的代码仍然是代码。

烂程序员也许会争辩说,他们注释掉这些代码是为了“万一”以后有人会需要它们。事实上,这好心反而是害了大家。这实际上说的是害怕风险,缺乏对版本控制系统作用的信任。有版本控制系统在,删除的代码永远不会真正的死掉。它们被埋到棺材里但却活着。所以,注释代码的方法没有多大实际效用。

zombie-by-aeviin-on-flickr

对于程序来说,注释掉的代码跟删掉的代码一样,不起任何作用。让代码半死不活,以僵尸的形态存在,造成技术债务,最终会让你的团队受害。要果断,删掉它们。

僵尸代码降低信噪比

当写程序时,我们一定要努力使代码里有效信息的比率越高越好。这有助于人们理解程序,更快的阅读代码,防止我们因为误解而写出有问题的代码。僵尸代码直接的对抗代码的可理解性。它拖延我们阅读和维护代码的速度,因为它使我们在屏幕上看到更少的有效代码。它们就是视觉噪音,干扰人们的正常阅读。处于某些原因,有些程序员会接受这种妥协的做法,可是在现实中,谁会接受这种乱糟糟的画面。想象一下,如果纽约时报看起来像这个样子:

nyt

如何阅读这断断续续的文字?噪音的增加就是对可理解性的损害。对这些被注释掉的部分,尽管它们毫不相干,甚至会误导,但你却无法对它们视而不见。有人会说,这不是最终发布的产品,这些代码存在于开发过程中,拿它们跟发布的产品做对比,这就像拿苹果比桔子。但是请记住,被写出的每行代码平均都要被阅读10次。没错,你的代码的阅读人数没有纽约时报多,但是,你拥有的是一个最重要的忠实的阅读群体。就是我们。 Knuth对此关切进行了精辟的总结:

“编程是一种一个人告诉另一个人他想让计算机做什么的艺术。” Donald Knuth

而僵尸代码让你讲话讲不清楚。一个程序员需要去阅读被注释掉的代码吗?

僵尸代码造成歧义妨碍调试

注释掉的代码会带来歧义,人们会怀疑这些代码是否该注释掉。试想一下,你是一个来维护程序的程序员,突然看到了一片注释掉的代码,而程序就在这附近出了问题。这个程序员的任务会变得更棘手。他需要阅读和理解这些注释掉的代码,了解注释它们带来的影响。是因为测试而注释这些代码但忘了恢复吗?也许注释这些代码的人可以提供帮助,但他是谁?调查行动开始。多余的歧义会消耗你的时间,增加你的思考负担——本来可以是一次轻松的调试过程。

僵尸代码影响关键词搜索

在大型程序库中,grep/find命令将会是你锁定某些特定的代码片段的雷达。然而,如果程序库里到处散布着僵尸代码,很有可能你捕捉到的目标都是被注释掉的。这是干扰。浪费时间。

僵尸代码影响代码重构

反省(重构)能修复我们的灵魂。我们应该以小孩scout的做事原则为荣,永远把代码收拾得比你想象的要整洁。然而,当一个类或方法包含有大量的僵尸代码时,事情就不好处理了。如果重构这段程序,我是否还要参考注释掉的代码?它们近期将会被重新使用吗?它会影响我的新版的实现吗?这些问题对于维护的程序员来说本该不需要回答的。

此外,集成重构工具根本不会考虑这些注释掉的代码。因此,当方法,变量,类被重命名或修饰符改变时,这些注释掉的代码就不会同步做修改。当你再想把注释掉的代码复活时,它们很可能根本不能编译。

有例外吗?

没有。很明确。有人会说“我现在注释它们是因为我过会儿就要恢复它们。”OK,假设你是个家庭妇男,你走到起居室,看到:

taped-switch

想想你内心的对话。这是个漂亮的房子,但这个东西又丑且怪异。我想开灯,但怎么会有胶带?如果我撕掉胶带去开灯,会发生什么事情?你很可能最终决定找贴胶带的人。“哦,我想打开吊扇,但它启动时来回摇摆,掉了下来,我想修理它….”当然,这是应该的。而在你没修好它之前,胶带一直贴在开关上。我们当然不该让这些只修了一半的东西存在屋内。同样,我们也不接受这样的代码。

说的更明白些,任何被注释掉的代码都是僵尸代码,都应该被删掉。不管有多少。不管是在发布的产品中还是在开发环境中。僵尸代码有时会在生死之间摇摆。如果代码被注释掉,这很有可能有东西没有完成。经常是配置需要来回切换或逻辑分支左右摇摆。注释代码可能会做实验性的来回切换,删除这些代码,建一个记事贴,记录下需要做的事情。在记事贴中记下哪次提交版本时删除了这些代码。或者,新建一个版本分支专门做这事,合并时删除它们。这样,维护工作就不会受到干扰。

心里的核对表

如果你打算要注释一段代码,请先问问自己:

  • 如果有可能的话,什么时候会取消注释?
  • 是否能删掉它,如果日后有需要,从版本控制系统里找回?
  • 对这些未完成的、有可能会回滚的代码,能否用版本分支来处理?
  • 这种需要来回切换注释的功能可否通过配置实现?
  • 重构时也需要重构这些注释掉的代码吗?

让我们开启第一次年度万圣节僵尸代码大清剿。

注:本文转自:http://www.aqee.net/kill-the-zombies-in-your-code/,[英文原文:Kill the Zombies in Your Code ]

» 文章出处: reille博客—http://velep.com , 如果没有特别声明,文章均为reille博客原创作品
» 郑重声明: 原创作品未经允许不得转载,如需转载请联系reille#qq.com(#换成@)
分享到:

 Leave a Reply

(必须)

(我会替您保密的)(必须)


*

   
© 2012 velep.com | reille blog | 管理| 粤ICP备12094833号-2| 谷歌地图| 百度地图| Suffusion theme|Sayontan Sinha

无觅相关文章插件,快速提升流量