你好，我是坤哥
近期在查阅过去几年的项目代码时发现了一个很多人都会犯的一个错误：在项目中留下了大量的僵尸代码，不光是过去，包括现在的工程项目在 code review 时也经常发现这种问题，所以我觉得这应该是个共性问题，这让我想起了之前看到的一篇文章，我觉得它把为什么不用僵尸代码几个点总结的非常好，我在此基础上作了一些修改分享给大家
所谓僵尸代码是指很多被注释的代码，为什么称它们为僵尸代码？你知道，僵尸不并不是真的死的。就像恐怕电影里告诉我们的，尽管僵尸看起来是死人，但它们仍有能力四处出没袭击我们。相同的道理，僵尸代码也是处于不生不死之间…它们在伺机搞砸我们的工作。注释掉的代码还活着，它们就存在我们的代码库中。程序员在维护和重构代码时会和它们遭遇，通常是滚动屏幕时和它们擦肩而过，或是在进行关键词搜索时和它们撞个满怀。但这些代码也确实是死的，因为它们在软件产品中并不执行。因此，这些僵尸就应该被烧掉，立刻。
僵尸代码不死之躯
我认为，有两个原因导致了僵尸代码的肆虐：懒和害怕风险。懒程序员对代码有收藏癖。他们缺乏确信的勇气和清楚的认识去删除无用的代码，于是他们就把它们隐藏在注释里，期望有朝一日它们能复活来再次祸害人。代码需要经常的、有计划的删除，因为优秀的程序员都知道：代码就是债务。越少越好。当然，被注释掉的代码仍然是代码。
烂程序员也许会争辩说，他们注释掉这些代码是为了“万一”以后有人会需要它们。事实上，这好心反而是害了大家。这实际上说的是害怕风险，缺乏对版本控制系统作用的信任。有版本控制系统在，删除的代码永远不会真正的死掉。它们被埋到棺材里但却活着。所以，注释代码的方法没有多大实际效用。
对于程序来说，注释掉的代码跟删掉的代码一样，不起任何作用。让代码半死不活，以僵尸的形态存在，造成技术债务，最终会让你的团队受害。要果断，删掉它们。
僵尸代码降低信噪比
当写程序时，我们一定要努力使代码里有效信息的比率越高越好。这有助于人们理解程序，更快的阅读代码，防止我们因为误解而写出有问题的代码。僵尸代码直接的对抗代码的可理解性。它拖延我们阅读和维护代码的速度，因为它使我们在屏幕上看到更少的有效代码。它们就是视觉噪音，干扰人们的正常阅读。处于某些原因，有些程序员会接受这种妥协的做法，可是在现实中，谁会接受这种乱糟糟的画面。想象一下，如果纽约时报看起来像这个样子：
如何阅读这断断续续的文字？噪音的增加就是对可理解性的损害。对这些被注释掉的部分，尽管它们毫不相干，甚至会误导，但你却无法对它们视而不见。有人会说，这不是最终发布的产品，这些代码存在于开发过程中，拿它们跟发布的产品做对比，这就像拿苹果比桔子。但是请记住，被写出的每行代码平均都要被阅读10次。没错，你的代码的阅读人数没有纽约时报多，但是，你拥有的是一个最重要的忠实的阅读群体。就是我们。Knuth对此关切进行了精辟的总结：
“编程是一种一个人告诉另一个人他想让计算机做什么的艺术。” Donald Knuth
而僵尸代码让你讲话讲不清楚。一个程序员需要去阅读被注释掉的代码吗？
僵尸代码造成歧义妨碍调试
注释掉的代码会带来歧义，人们会怀疑这些代码是否该注释掉。试想一下，你是一个来维护程序的程序员，突然看到了一片注释掉的代码，而程序就在这附近出了问题。这个程序员的任务会变得更棘手。他需要阅读和理解这些注释掉的代码，了解注释它们带来的影响。是因为测试而注释这些代码但忘了恢复吗？也许注释这些代码的人可以提供帮助，但他是谁？调查行动开始。多余的歧义会消耗你的时间，增加你的思考负担——本来可以是一次轻松的调试过程。
僵尸代码影响关键词搜索
在大型程序库中，grep/find命令将会是你锁定某些特定的代码片段的雷达。然而，如果程序库里到处散布着僵尸代码，很有可能你捕捉到的目标都是被注释掉的。这是干扰。浪费时间。
僵尸代码影响代码重构
反省(重构)能修复我们的灵魂。我们应该以小孩scout的做事原则为荣（永远让营地比你来之前更加干净。），永远把代码收拾得比你想象的要整洁。然而，当一个类或方法包含有大量的僵尸代码时，事情就不好处理了。如果重构这段程序，我是否还要参考注释掉的代码？它们近期将会被重新使用吗？它会影响我的新版的实现吗？这些问题对于维护的程序员来说本该不需要回答的。
此外，集成重构工具根本不会考虑这些注释掉的代码。因此，当方法，变量，类被重命名或修饰符改变时，这些注释掉的代码就不会同步做修改。当你再想把注释掉的代码复活时，它们很可能根本不能编译。
有例外吗？
没有。很明确。有人会说“我现在注释它们是因为我过会儿就要恢复它们。”OK，假设你是个家庭妇男，你走到起居室，看到：
想想你内心的对话。这是个漂亮的房子，但这个东西又丑且怪异。我想开灯，但怎么会有胶带？如果我撕掉胶带去开灯，会发生什么事情？你很可能最终决定找贴胶带的人。“哦，我想打开吊扇，但它启动时来回摇摆，掉了下来，我想修理它….”当然，这是应该的。而在你没修好它之前，胶带一直贴在开关上。我们当然不该让这些只修了一半的东西存在屋内。同样，我们也不接受这样的代码。
说的更明白些，任何被注释掉的代码都是僵尸代码，都应该被删掉。不管有多少。不管是在发布的产品中还是在开发环境中。僵尸代码有时会在生死之间摇摆。如果代码被注释掉，这很有可能有东西没有完成。经常是配置需要来回切换或逻辑分支左右摇摆。注释代码可能会做实验性的来回切换，删除这些代码，建一个记事贴，记录下需要做的事情。在记事贴中记下哪次提交版本时删除了这些代码。或者，新建一个版本分支专门做这事，合并时删除它们。这样，维护工作就不会受到干扰。
心里的核对表
如果你打算要注释一段代码，请先问问自己：
- 如果有可能的话，什么时候会取消注释？
- 是否能删掉它，如果日后有需要，从版本控制系统里找回？
- 对这些未完成的、有可能会回滚的代码，能否用版本分支来处理？
- 这种需要来回切换注释的功能可否通过配置实现？
- 重构时也需要重构这些注释掉的代码吗？
如何查阅被删除掉的僵尸代码
上文已经把僵尸代码的危害说得很清楚了，不过这里我还是想额外提一点，如何查阅被删掉的僵尸代码？毕竟某些功能被下掉后重新上线也是可能的，此时我想直接复用之前被删掉的代码该怎么办呢，以 git 为例，主要有以下几个方法
1、 首先根据提交时的 commit message 来查找对应的 commit，然后再查找此 commit 对应的 diff，比如我想查找 commit message 中包含「删除账户」这个信息的的 commit，可以先根据git log --grep="删除账户"这样的命令过滤出所有的 commit，会显示所有 commit message 中包含有「删除账户」的 commit（模糊匹配），如下
再根据 git show commitId，可查看此 commit 的 diff，所以为什么我们一直要强调 commit message 要写规范，通过这种方式特别容易找到你想看的 diff
2、 可能有人会说我忘记了对应的 commit message，但记得在在哪个文件改的，那也简单，使用如下命令可以查看此文件的所有历史提交记录
git log --follow -p -- path-to-file
