干掉代码中的僵尸代码

---

大家平时在做项目的时候肯定都接触过代码库里都四处散乱着很多小段注释的代码，甚至大片大片的被注释掉的代码。这就是僵尸代码。


为什么称它们为僵尸代码？你知道吗，僵尸其实并不是真的死的。就像恐怕电影里告诉我们的，尽管僵尸看起来是死人，但它们仍有能力四处出没袭击我们。相同的道理，僵尸代码也是处于不生不死之间…它们在伺机搞砸我们的工作。注释掉的代码还活着，它们就存在我们的代码库中。程序员在维护和重构代码时会和它们遭遇，通常是滚动屏幕时和它们擦肩而过，或是在进行关键词搜索时和它们撞个满怀。但这些代码也确实是死的，因为它们在软件产品中并不执行。因此，这些僵尸就应该被烧掉，立刻。

僵尸代码不死之躯

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

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

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

僵尸代码降低信噪比

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

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

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

僵尸代码影响关键词搜索

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

僵尸代码影响代码重构

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

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

心里的核对表

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

让我们开启僵尸代码大清剿吧！