是时候清除你的僵尸代码了

摘要:僵尸代码是指你的代码库里被注释掉的那部分代码,你常常受它们困扰,却很少去使用它,就像僵尸一样,明明死去了还到处作祟。你没有任何理由去保留这样的代码,是时候把它们完全清除了!

随着万圣节的临近,是时候讨论一下软件开发中广泛存在的问题了:僵尸代码。我参与的每一个代码库中都或多或少被注释掉的代码,也就是所谓的“僵尸代码”。

  1. //暂时关闭这个特性,Jimmy在写这段代码的时候肯定是喝醉了。 
  2. //他对代码做了什么可怕的事……幸好被注释掉了。 

那为什么叫它们僵尸代码呢?因为僵尸并没有真正死去,正如恐怖电影上所呈现的,尽管僵尸已经死了,但它仍然足够困扰我们。某种意义来说,僵尸代码实际上介于活与死之间……只是等待某一天来毁掉你的生活。说注释掉的代码是活的,因为它还存在在代码库里,程序员会在维护和重构过程继续与之打交道,也许只是扫一眼,或者出现在某个关键字搜索的结果中。但它也是死的,因为它并没有真正在产品里起作用。因此需要尽快地把它埋葬掉!

今天代码不会真正地死去

我认为出现僵尸代码的两大主要原因在于:懒惰和风险规避。懒惰的开发者经常复制代码,他们没有责任感、也不敢删去其中多余的代码,所以将它们注释掉,以便以后起作用。代码需要经常地整理,因为优秀的开发者认为代码即是负债,less is more!毫无疑问,注释掉的代码仍然是代码。

懒惰的开发者可能会辩解这些注释掉的代码是为了“以防万一”,它可能会在以后起作用。它恰恰帮了倒忙。这是对风险的逃避,明显缺少对版本控制优点的认识。有了版本控制,被删去的代码并没有真正消失,它可能会在某个需要的时候复活。因此注释代码是一个更差的选择。

注释掉的代码对于应用来说和删除掉的代码一样没有意义。僵尸代码是一种技术债务,会在将来给你的团队带来困扰,坚决点,删掉它吧!

改善信噪比

写代码的时候,我们必须尽可能地增加信噪比,这能够增进理解和快速阅读,并且可以帮助我们免于因误解而写出充满bug的代码。僵尸代码刚好起反作用。它阻碍了代码阅读和维护,因为它减少了屏幕上有意义的内容比例。这是视觉噪音,因为你不能确定自己是否可以跳过这段代码。由于某些原因,我们这些开发者经常会妥协,但我们在现实世界中并没有这样妥协过,想想一下纽约时报是这样:

阅读这样的语句的感觉怎么样?噪音的增加会影响理解程度。你会发现很难忽略掉注释区域,即是它是没有意义的,更糟的是,它甚至可能是误导性的和错误的。也许你会认为“源代码并不是最终产品”,所以把它和最终产品比较就像是苹果和橘子之间的关系。要记住,每一行代码平均会被阅读10次。的确,我们的读者比不上Times,但他们都是忠实的读者。Knuth认为这会影响完美度。

“编程是一种艺术,目的在于告诉其他人他想要让计算机做什么”——Donald Knuth

僵尸代码却让这一切变得模糊不清,程序员是否应该花时间阅读注释掉的代码?

歧义妨碍了调试

注释掉的代码会制造这些代码是否已经被评论过的歧义。想想你是一个代码维护人员,在出现bug的代码附近出现了很多僵尸代码,这样你的工作会变得倍加困难。你需要预读并理解僵尸代码才知道它是否会有潜在影响。是因为测试而注释掉的却没有恢复?也许注释的人会知道这是为什么,但他是谁呢?因此你又需要去调查,多余的歧义使得你不得不花多倍的时间来解决,并把本来简单的调试环节弄得复杂了。

关键字搜索优化

在更大的代码库中,grep/find能够用来快速定位代码片段。然而,如果代码库中充满了僵尸代码,那么目标代码出现的频率就会大幅下降,浪费开发/维护人员的时间。

更简单的重构

重构对代码的好处不言自明,我们应该尊重“童子军规则”(boy scout rule),定期优化代码。然而,如果方法或者类中充满了僵尸代码的话,事情就变得复杂了。在重构代码段的时候需要考虑注释掉的代码吗?它不久后会恢复吗?它会跟我新的实现互相影响吗?你不该让维护人员问出这些问题。

另外,集成重构工具并不会对注释掉的代码做任何修改。因此,方法、变量或者类重命名了或者签名改变了,注释掉的代码就落后了,这事再重用它的话,应用很可能就难以通过编译了。

有什么例外吗?

没有!这些都是非常显而易见的,你也许会辩解“我之所以注释掉这段代码是因为我打算之后重用它。”好吧,想象你在看房子,并且在客厅看到这个:

想想你内心里是什么反应。这的确是个不错的房子,但这个难看而且古怪。我想开灯,但这个胶条是做什么的?如果我把胶条撕掉会怎么样?你可能会打算先问问房主。“哦,我添加了一个吊扇,但在我打开它时掉到地上了,我过一会在修好它。”但奇怪的开关不会消失。如果你并不希望自己家里存在这样半吊子的功能,为什么在代码里你就允许这样?

澄清一下,任何注释掉的代码都是僵尸,都是应该清除掉的,无关质量。代码要么会在产品中出现,要么它就不该出现。僵尸代码可怕之处在于它刚好处于这两种状态之间。如果代码被注释掉了那它应该还没有完成。通常,一个设置转变或者逻辑分成,所以代码仅仅在合适的时候运行。删掉那段代码,并且保证必要的工作已经完成了,这个保证包括应当提交一个引用,说明哪里的代码被删掉了。或者,你也可以将未完成的代码,移入一个专门的分支,只有在完全实现后才添加到主分支中。这样的话,维护工作并不会收到歧义的影响。

我的意见

如果你打算注释掉代码,先问问自己:

  1. 如果需要,应该什么时候取消注释?
  2. 有必要的话,我以后能通过版本控制再找回这段代码吗?
  3. 这个未完成的工作应该放入一个分支中吗?
  4. 这个功能可以通过配置开启/关闭吗?
  5. 我会为这段代码重构需求吗?

让我们把这个一年一度的万圣节变成僵尸狩猎之夜吧!

posted @ 2013-01-03 22:27  N3verL4nd  阅读(220)  评论(0编辑  收藏  举报