朋友，请待你的朋友——BUG好一点！

　　程序猿嘛，难免会被BUG缠身，我相信，没有一个程序猿在被BUG缠身时是感觉轻松的，消灭BUG一定是你最大的愿望。本周，我们团队的项目进入调试阶段，各种BUG层出不穷，眼看下个周就要进行项目答辩会，所以每个成员都绷紧了神经，与时间赛跑，一路过关斩将，解除一个一个的BUG。今天，我们就来简单谈一下，我们应该如何对待这位特殊的“朋友”——BUG：

　　BUG，一种传说中的昆虫类爬行动物。形状多变，往往根据生存环境随意变换其外形特征。常常和一类叫做“程序猿”的灵长类动物共存。程序猿在工作之余，常以捕杀BUG作为消遣。当某些BUG演变成具有较大破坏性的时候，需要集体捕杀，或是替别人捕杀BUG的情况也时有发生。

　　一个项目的推进，通常有四种情况：

　　第一种，负责的程序猿，紧张的进度——这种情况往往是快速试错、快速迭代的开发流程，开发过程中，可能会出现一些BUG，但因为程序猿是负责的，项目收尾时会有自发的BUG清理；

　　第二种，不负责的程序猿，紧张的进度——情况基本和第一种情况类似，但是在最后项目中会埋下很多未处理的BUG的蛹，给维护带来很多不便和负担；

　　第三种，负责的程序猿，不那么紧张的进度——这种时候可以不满不慌的，三思而后行，这样一来BUG会很少，而且也不好留下BUG的蛹，甚至会出现BUG Free的情况，但是开发速度有点缓慢；

　　第四种，不负责任的程序猿，进度是不是紧张，他们不管——做得越少，错得越少。这种情况下，BUG会大量滋生，最终可能会危及整个项目的人身安全，而且项目能不能如期完成，程序猿也高高挂起。

　　不管在项目开发中，处于哪一种状态，在进度与责任之间，程序猿的平衡直接导致了BUG的滋生与否，但是还有一个原因，那就是上层管理者的态度。如果一个项目中有很多BUG，而且有一些因为寄生太久，已经搞不清是从哪里冒出来的，又要怎么捕杀这些BUG从而力求达到一个BUG Free的环境？

　　团队很小的时候，可以自发指定一些规则，大家自觉维护代码的质量，BUG一抓一个准，抓一个修一个。。一些平时因为种种情况（懒、耍滑、太忙、不太懂······）从来对BUG都是连推带拖的人，找他抓BUG的人会很少，对这种人而言，系统了解不少，但是也省出了一些时间。所以从某种意义上来讲，不部分所有权明确的BUG很容易被处理，而一些三不管地带的BUG往往可以被一再忽视，成为千年老BUG，给项目的运营带来隐患。比如，这里有些某项目遗留的BUG，但是整个项目组的拆了；再比如，一个前员工留下的BUG，但是这个人已经离开很久了······而这样的BUG，如果没有从上层发起重视和方案，或者是几个真正把公司的事看成自己的事的能人，往往不论英雄多少用户，都不会被重视。这时，有人可能会说：可以通过一定的奖励机制来鼓励维修BUG。但是， 这种机制也会遭到质疑：1.奖励修BUG，必然有很多组投身修理更多的BUG，这会不会伤害到代码的质量呢？2.修理自己的BUG，该不该奖励？3.有人会过度热衷于修BUG而影响正常的开发工作？

　　说到这里，我不禁想起了某公司的一位高管所说的一句话：很多BUG的道路，就好像在没有告诉公路上行驶的很多车辆。不论怎样，你都快不了。当有这样一个机制来鼓励清理BUG时，就好像是修了一条高速公路。这虽然不能保证所有的时候所有的车都可以畅通无阻，也不可避免所有的人开始飙车，引起别的问题。但至少，在这条路上，除非出了事故，否则你就有了最低限速，确保大部分时候，还是比没有这条路时，交通要好的多。你们说呢？

　　清理BUG，奖励清理BUG，待BUG好一点，你的项目会绽放出更美丽的花朵！