干掉你程序中的僵尸代码

推荐阅读20121127 干掉你程序中的僵尸代码 随着万圣节越来越流行，我感觉有必要跟大家讨论一下一个在软件开发中非常普遍的问题：僵尸代码。几乎所有我接触过的代码库里都四散着很多小段的，甚至大片大片的被注释掉的代码。这就是僵尸代码。 //目前禁用这项功能。Jimmy在写这段代码时肯定是喝醉了。 //你可能以为这里发生了恐怖的代码凶手案…不，不，我只是把它们注释掉了… 为什么称它们为僵尸代码？你知道，僵尸不并不是真的死的。就像恐怕电影里告诉我们的，尽管僵尸看起来是死人，但它们仍有能力四处出没袭击我们。相同的道理，僵尸代码也是处于不生不死之间…它们在伺机搞砸我们的工作。注释掉的代码还活着，它们就存在我们的代码库中。程序员在维护和重构代码时会和它们遭遇，通常是滚动屏幕时和它们擦肩而过，或是在进行关键词搜索时和它们撞个满怀。但这些代码也确实是死的，因为它们在软件产品中并不执行。因此，这些僵尸就应该被烧掉，立刻。 僵尸代码不死之躯 我认为，有两个原因导致了僵尸代码的肆虐：懒和害怕风险。懒程序员对代码有收藏癖。他们缺乏确信的勇气和清楚的认识去删除无用的代码，于是他们就把它们隐藏在注释里，期望有朝一日它们能复活来再次祸害人。代码需要经常的、有计划的删除，因为优秀的程序员都知道：代码就是债务。越少越好。当然，被注释掉的代码仍然是代码。 烂程序员也许会争辩说，他们注释掉这些代码是为了“万一”以后有人会需要它们。事实上，这好心反而是害了大家。这实际上说的是害怕风险，缺乏对版本控制系统作用的信任。有版本控制系统在，删除的代码永远不会真正的死掉。它们被埋到棺材里但却活着。所以，注释代码的方法没有多大实际效用。 对于程序来说，注释掉的代码跟删掉的代码一样，不起任何作用。让代码半死不活，以僵尸的形态存在，造成技术债务，最终会让你的团队受害。要果断，删掉它们。 僵尸代码降低信噪比 当写程序时，我们一定要努力使代码里有效信息的比率越高越好。这有助于人们理解程序，更快的阅读代码，防止我们因为误解而写出有问题的代码。僵尸代码直接的对抗代码的可理解性。它拖延我们阅读和维护代码的速度，因为它使我们在屏幕上看到更少的有效代码。它们就是视觉噪音，干扰人们的正常阅读。处于某些原因，有些程序员会接受这种妥协的做法，可是在现实中，谁会接受这种乱糟糟的画面。想象一下，如果纽约时报看起来像这个样子： 如何阅读这断断续续的文字？噪音的增加就是对可理解性的损害。对这些被注释掉的部分，尽管它们毫不相干，甚至会误导，但你却无法对它们视而不见。有人会说，这不是最终发布的产品，这些代码存在于开发过程中，拿它们跟发布的产品做对比，这就像拿苹果比桔子。但是请记住，被写出的每行代码平均都要被阅读10次。没错，你的代码的阅读人数没有纽约时报多，但是，你拥有的是一个最重要的忠实的阅读群体。就是我们。 Knuth对此关切进行了精辟的总结： “编程是一种一个人告诉另一个人他想让计算机做什么的艺术。” Donald Knuth 而僵尸代码让你讲话讲不清楚。一个程序员需要去阅读被注释掉的代码吗？ 僵尸代码造成歧义妨碍调试 注释掉的代码会带来歧义，人们会怀疑这些代码是否该注释掉。试想一下，你是一个来维护程序的程序员，突然看到了一片注释掉的代码，而程序就在这附近出了问题。这个程序员的任务会变得更棘手。他需要阅读和理解这些注释掉的代码，了解注释它们带来的影响。是因为测试而注释这些代码但忘了恢复吗？也许注释这些代码的人可以提供帮助，但他是谁？调查行动开始。多余的歧义会消耗你的时间，增加你的思考负担——本来可以是一次轻松的调试过程。 僵尸代码影响关键词搜索 在大型程序库中，grep/find命令将会是你锁定某些特定的代码片段的雷达。然而，如果程序库里到处散布着僵尸代码，很有可能你捕捉到的目标都是被注释掉的。这是干扰。浪费时间。 僵尸代码影响代码重构 反省(重构)能修复我们的灵魂。我们应该以小孩scout的做事原则为荣，永远把代码收拾得比你想象的要整洁。然而，当一个类或方法包含有大量的僵尸代码时，事情就不好处理了。如果重构这段程序，我是否还要参考注释掉的代码？它们近期将会被重新使用吗？它会影响我的新版的实现吗？这些问题对于维护的程序员来说本该不需要回答的。 此外，集成重构工具根本不会考虑这些注释掉的代码。因此，当方法，变量，类被重命名或修饰符改变时，这些注释掉的代码就不会同步做修改。当你再想把注释掉的代码复活时，它们很可能根本不能编译。 有例外吗？ 没有。很明确。有人会说“我现在注释它们是因为我过会儿就要恢复它们。”OK，假设你是个家庭妇男，你走到起居室，看到： 想想你内心的对话。这是个漂亮的房子，但这个东西又丑且怪异。我想开灯，但怎么会有胶带？如果我撕掉胶带去开灯，会发生什么事情？你很可能最终决定找贴胶带的人。“哦，我想打开吊扇，但它启动时来回摇摆，掉了下来，我想修理它….”当然，这是应该的。而在你没修好它之前，胶带一直贴在开关上。我们当然不该让这些只修了一半的东西存在屋内。同样，我们也不接受这样的代码。 说的更明白些，任何被注释掉的代码都是僵尸代码，都应该被删掉。不管有多少。不管是在发布的产品中还是在开发环境中。僵尸代码有时会在生死之间摇摆。如果代码被注释掉，这很有可能有东西没有完成。经常是配置需要来回切换或逻辑分支左右摇摆。注释代码可能会做实验性的来回切换，删除这些代码，建一个记事贴，记录下需要做的事情。在记事贴中记下哪次提交版本时删除了这些代码。或者，新建一个版本分支专门做这事，合并时删除它们。这样，维护工作就不会受到干扰。 心里的核对 如果你打算要注释一段代码，请先问问自己： ● 如果有可能的话，什么时候会取消注释？ ● 是否能删掉它，如果日后有需要，从版本控制系统里找回？ ● 对这些未完成的、有可能会回滚的代码，能否用版本分支来处理？ ● 这种需要来回切换注释的功能可否通过配置实现？ ● 重构时也需要重构这些注释掉的代码吗？ 让我们开启第一次年度万圣节僵尸代码大清剿。 Kill the Zombies in Your Code With Halloween nearly upon us, it seems appropriate to discuss a widespread problem in software development: zombie code. Nearly every codebase I work with is littered with small chunks or large swaths of commented out code. This is zombie Code. //Turning this feature off for now. Jimmy was clearly drinking when he wrote this. //Imagine horrible crimes against code here...but at least it's commented out... So why call it zombie code? Well, zombies aren’t really dead. As horror movies have taught us, though zombies appear to be dead, they’re still alive enough to haunt us. In the same way, zombie code straddles the line between alive and dead…just waiting for a chance to ruin your day. Commented out code is alive because it’s in the current codebase. Programmers interact with it during maintenance and refactoring, often by simply scrolling quickly past or stumbling across it in a keyword search. But the code is also dead because it’s not executed in production. Thus, it’s a zombie that should be buried, pronto. Today’s Code Never Really Dies I propose there are two root causes for the ongoing scourge of zombie code: Laziness and risk aversion. Lazy developers get attached to code. They lack the strength of conviction and sense of purpose required to delete unnecessary code, so they hoard it in comments instead where it can live to haunt another day. Code must be deleted regularly because great developers know that code is a liability. Less is more. And yes, commented out code is still code. Lazy developers may argue that they comment out code “just in case” it might be useful to someone later. This does us all a disservice. It speaks to risk aversion and a lack of appreciation for the benefits of source control. With source control, deleted code never really dies. It’s merely buried alive. Thus, commenting out code is weak sauce. Commented out code is just as useless to the application as deleted code. Straddling the fence creates technical debt in the form of zombie code that will haunt your team later. Be decisive. Delete it. Improved Signal To Noise When writing code, we must strive to keep our signal to noise as high as possible. This aids in comprehension, speeds reading, and helps protect us from creating buggy code due to misunderstanding. Zombie code is directly opposed to comprehension. It slows reading and maintenance because less actual production code is on the screen at any given time. It’s visual noise because it’s unclear if one should read it at all. For some reason we often accept this compromise as developers, but we’d never accept such sloppiness in the real world. Imagine if the New York Times looked like this. Notice how reading the text doesn’t flow? The increased noise hurts comprehension. And it’s difficult to ignore the commented section even though it’s likely irrelevant, or worse misleading and incorrect. One could argue that source code isn’t the finished product, so a comparison to a finished publication is apples and oranges. But we must remember that every line of code written will be read an average of ten times. So yes, our readership is smaller than the Times, but it’s an important readership with a loyal following. It’s us. Knuth sums up this concern perfectly. “Programming is the art of telling another human what one wants the computer to do.” Donald Knuth Zombie code makes the story unclear. Should a programmer spend time reading the commented out code or not? Ambiguity Hinders Debugging Commented code creates ambiguity about whether the code should have been commented at all. Imagine you’re a maintenance programmer who stumbles across a swath of zombie code around an area where a bug has been reported. The programmer’s job is now much harder. The commented code must be read and comprehended to determine its potential impact. Was the code accidentally commented out for testing and never reverted? Perhaps the person who commented it out can be of help. Who was that? An investigation ensues. This additional ambiguity takes time to resolve and adds mental weight to what could otherwise be a simple debugging process. Keyword Search Optimization In larger code bases, grep/find in files can be a lifesaver for hunting down specific pieces of code. However, if the code base is littered with zombie code, chances are many hits will contain commented code. It’s just noise. And wasted time. Simpler Refactoring Refactoring is good for the soul. We should be honoring the boy scout rule and regularly leaving the code a little better than we found it. However, when a class or method contains a chunk of zombie code, things get tricky. If I refactor this section, do I need to consider this commented out code? Will it be turned back on soon? How will it interact with my new implementation? These are questions maintenance programmers shouldn’t have to ask. Furthermore, integrated refactoring tools won’t make corresponding changes to commented out code at all. Thus, as methods, variables, and classes are renamed and signatures are changed, the commented code falls behind. When commented out code is resurrected, it’s highly likely the app won’t even compile. Any Exceptions? Nope. See that was easy. And definitive. One could argue “I’m commenting this section out for now because I plan to uncomment it again soon.” Okay, say you’re house-sitting. You walk in the living room and see this: Imagine your inner dialogue. It’s a nice house, but that’s ugly and odd. I need to turn on the light, but what’s with the tape? What would happen if I removed the tape and turned it on? You’ll likely decide to call the owner. “Oh, I put in a ceiling fan but it wobbles and crashes to the floor when I turn it on. I’ll fix it…at some point.” Yeah, sure you will. Until then, the bizarre taped switch remains. We don’t accept disabled half-baked features in our homes, why should we do so in the code we support? To clarify, commented out code is zombie code that should deleted, regardless of quality. Code is either in production, or it’s not. Zombie code sits at some scary point in between. If code is commented out, then it’s likely not done. Often a configuration switch or logic fork is needed so the code is only exercised when appropriate. Delete the code and open a ticket to assure the necessary work is completed. In that ticket, include a reference to the commit where the code was deleted. Alternatively, move the work to a dedicated branch where it should stay until fully fleshed out. In the meantime, maintenance work will not be impeded by the ambiguity. A Mental Checklist If you’re about to comment out code, ask yourself: · When, if ever, would this be uncommented? · Can I delete this and simply get it from source control later if necessary? · Is this incomplete work that should be rolled back and worked via a branch? · Is this a feature that should be enabled/disabled via configuration? · Did I refactor out the need for this code? Let’s make this the first annual Halloween zombie code hunt. 欢迎免费随堂试听天一时代Java企业技术培训 上课时间：周一至周五16：30-19：30 讲师：刘学愚：天一时代项目经理，多年从事对日项目开发及管理工作，曾就职日本Livedoor公司。主要客户有日本三菱重工，NEC，富士通，住友银行，东海铁路株式会社等。精通J2EE、Oracle平台下系统分析与设计开发，对基于J2EE架构项目的设计开发具备丰富的项目经验；曾主持参与多个大型项目的管理和开发。 地址：哈尔滨市哈平路副85-2号盛世闲庭205室 乘车路线：28、51、67、69、81、208、209、217、338、371花卉市场站下车，或9路、10路、18路、52路、56路、62路、68路、73路、75路、101路、102路、117路三大动力路下车，步行至盛世闲庭 【黑龙江大学、哈理工（西区）、哈学院】乘坐67、209、217花卉市场站下车，车程约15分钟 【东北林业大学、哈理工（东区）、哈理工（南区）】可直接步行来公司，路程约10分钟 【剑桥】乘坐81、338花卉市场下车，车程25分钟 【农大】乘坐69线花卉市场下车，车程45分钟 学习Java或android过程中，如果遇到技术问题，欢迎与天一时代保持联络，我们的技术人员将为爱好技术的学生，提供无偿的、力所能及的帮助！