http://blog.csdn.net/wojiushiwo987/article/details/8851204为什么我没有拔出钥匙

                            ——开锁引发的程序bug解决方案的思考

       今天中午回宿舍的时候，舍友S开完锁以后，钥匙在锁槽里拔不出来了。以前只是锁不怎么好用，左旋右旋活几下1分钟之内就能打开了。这次，的确可能卡的比较紧吧，室友S旋转了好久没有打开。然后，我接过来弄了好久（几乎同样的方法）也没有打开。此时室友S告诉我，他上午给老师屋开门，没有打开，钥匙断在里面了，刚报修了。此时，我的第一反应就是：别再尝试了，钥匙很脆，万一断在里面岂不是更麻烦，下午导师去实验室我还想着正点上班。

       这时候，我们隔壁宿舍J同学也过来了，多一个同学多一种思路吧，他也过来尝试拔出钥匙，也是试探了好久，未果。

       在他们试探的过程中，我想着：为了不耽误下午的进度，我去楼管阿姨那报修吧。阿姨说，修锁师傅可能去吃饭，你自己去看吧。去了两次，可能真去吃饭了，未果，然后跑回宿舍。

       舍友S还在尝试拔钥匙，因为有上次断钥匙的经历，只是反复小心翼翼试探着……

       这时，另一同学H看到我们在弄钥匙，也凑了过来。然后接过来，试图拔出钥匙。起初也是和我们一样，没有成效。但是反复抽插，加上顶着门插拔，钥匙被顺利拿了出来。

       我和舍友S感激之情溢于言表。而后，我们削了铅笔芯放在锁芯里，整个锁有了焕然一新的感觉，开锁、拔钥匙都很流畅了。

中午的时候，我对这件事反复思考……为什么我没有拔出钥匙呢？

       这让我联系到了程序设计的过程，并一一作了对应。

         1、正常开锁——程序正常运行，没有bug；

         2、钥匙拔不出来——程序运行有bug；

         3、反复试探拔出钥匙——普通方法试图修正bug；

         4、别的同学帮忙拔钥匙——同学帮忙解决bug；

         5、 找楼管阿姨保修——找特定技术人员（网络找技术博客、牛人）解决bug；

         6、舍友H顶着门插拔——另辟蹊径解决了bug；

         7、削铅笔芯放入锁芯——完善修正bug，消灭bug，避免程序再次出错。

         8、上次帮老师开门钥匙断了——以往程序经验会对bug产生积极或消极的影响，此次为消极影响，也是由于我的胆怯，听说钥匙断了，不敢大胆尝试。

         9、中午想不影响正常休息、下午正常上班——程序设计过程是有进度要求的，此时要考虑项目组负责人（如项目经理）的时间进度安排，还有自己的作息习惯。

        10、我和室友没有拔出钥匙——我们没有找到bug的所在。

        这样，整个开锁的过程就是程序的bug查找、修改、完善修正bug的过程。

        在拔出钥匙，即查找bug的过程中，我们用了3种方法。

        方法1：普通方法（反复试探拔出钥匙），即逐个排除bug；

        方法2：求助同学帮忙，即同学帮忙调试查找bug；

        方法3：求助楼管阿姨找技术人员保修，即等同于找IT专业大牛解决bug。

       当然，在方法1我和室友的试探过程中，我明显犯了经验主义的错误，即室友提到他上午帮老师开锁，结果钥匙都弄断了。此时，我一方面考虑自己的中午午休、下午上班的正常进度；另一方面也考虑万一钥匙断了有责任问题，也浪费了大把时间。我当时甚至想到：中午正常休息，下午继续保修。很显然，是我想的太多，其实完全没有必要。

       对比方法1、2、3；其实方法3可能是最快的（天时、地利、人和具备的条件下）。方法1可能最慢，并且可能有风险，在开锁的时候体现在可能钥匙断掉、耽误项目进度、耽误正常作息等，程序设计中则体现在bug没有找到、花费了很长时间、死机等情况。但回头想想，方法1自己动手、去尝试、去体验各种旋转（即对应解决bug的各种思路），如果万一bug找到，这时候自己回头去想整个找寻bug的过程，会很快乐，印象会很深，并且如果下次还有类似的bug出现，肯定能迎刃而解的。

       同学H过来后二话没说，接过来就是拔钥匙，各种传统方法并结合尝试新的方法，最终结果是，2分钟内钥匙拔出来了。让我想到的是，程序设计中当传统的方法无法解决问题时，可以考虑另辟蹊径，往往新思路会突破旧思维取得好的效果。但也可能会带来钥匙断掉的风险，即bug也未解决甚至死机的风险。但权衡下，这毕竟增加了胜算的可能。即前两天师弟所讲的“越努力、越幸运！”，从概率论的角度来讲，是成立的。

       这也让我想到之前和师弟们探讨过的问题：遇到bug后如何解决bug？这样经过开锁的经历后，我越发坚定了我的思路：

       第1：尽最大可能的自己通过手头已有的知识解决（已有的程序思维逻辑、手头有的笔记、书籍），如果一条路行不通，可以考虑回溯另辟新路去探索解决问题的方法。若该条方法在自己试探了N条路走都行不通的话，可以考虑第2条。

       第2：求助项目组的同学/同事，因为你们的项目接近，一起开发时可能会遇到类似的难题，这样，一起讨论可能很快就产生了解决问题的火花。如果第1、2条都行不通的话，可以考虑第3条。

       第3：查询互联网（Google搜索、CSDN搜索等），或者借助互联网论坛，如CSDN论坛、cnblog等里有不同的板块，可以考虑发帖求助。我试验过，第3条基本能解决1、2解决不了的难题。

       解决bug有时候是个痛苦的过程，甚至1天、2天都没有结果，但越是濒临绝望的边缘的时候，越不放弃对解决bug方法的希望。问题会得到解决的，届时，你会感觉：恍然大悟、醍醐灌顶。其不幸哉！

                                                                                                                    2013-4-25 pm 3:00于实验室