豪斯医生的除虫之道
电视剧《豪斯医生》终于要告一段落了。从第一季一直看到第八季，这可能是我除了《成长的烦恼》以及《神探亨特》以外又一部看全了的美剧。（当然像《英雄》《终结者编年史》这样半途而废的不算）
豪斯医生对我的吸引力，是在于其推理的内核。剧中豪斯所破解的种种病因，对我来说可以说是半点不懂。解释病因时如果没有那些动画，翻成中文我也不懂他在说什么。而那些医学名词，除了记住几个LP, CPR, Steoroid, kee-mo之类的词供以后装逼时用以外，也没剩下什么。但是电视剧本身推理的脉络，还是很清晰的：病人得了怪病，医生提出种种假设并去现场一一求证。医生钻进各种死胡同，最后灵光乍现破解案件。由于我对医术不懂，所以不好妄言这是不是本格推理，不过如果是找日本编剧写剧本的话，豪斯高太郎恐怕要在恍然大悟后在聚光灯下转向观众说：病人得的是xx病无疑了，那么我是怎样知道病人得的是xx病呢？电视机前的观众朋友们，我们一会见~~
撇开此剧的本格内核不说，豪斯医生诊断病情的方法竟也暗合我等软件工程师炼化代码中性命交关之头等大事–debugging.
Debugging相信当过软件工程师的朋友们都不陌生，那真是程序员的噩梦。记得我刚学写程序的时候，第一个稍有规模的程序（走迷宫），写好后调了一个礼拜才调通。相信各位的办公室中也常常流传着“某某bug过了半年才调出来”这样的传说。debugging是项目计划中最容易忽略的一部分，也是最不好估计的一部分。有多少程序员为了程序中的一个错茶不思，饭不想。也有的朋友因为承受不了半年调不出一个bug的压力，放弃了程序员这份职业。
豪斯医生的诊断思想却可以给debugging一个方法上的指导。豪斯的differential diagnosis，是一种系统的诊断病人病情的方法。他的方法有以下几个特点：
1. 根据症状列出可能的病因，并一一排除之。
豪斯医生诊断的阵势一向是把症状一一列在白板上，然后由众小强逐一提出能解释这些症状的病因，然后再逐一排除不能完美解释症状的病因。如果遇到不能确定的情况，则由众小强去做各种测试来验证。所以第一次会议后众小强验血的验血，拍片子的拍片子—-我多么希望我debug的时候也能有这么大阵势啊。
debugging也是这样，程序员首先要尽可能的收集和程序有关的信息，比如断点状态，程序log，错误表现等等。根据收集到的结果来对错误的原因做出各种猜测。如果不能够确定的，则会对代码进行单步或者插入更多调试信息等方法来排除错误猜想。
注意这一步的关键是排除，而不是证明。我们做的各种试验，目的是为了能够排除我们的某个猜想。关于一个错可以有各种猜测，但是只有一个是正确的（也可能一个都没有），这个阶段我们不是要选定一个方向深研进去，而是设计一个试验能够验证这些方法是否正确。所以要首先动手去排除那些容易排除的原因。我常常看到一些程序员盯着某个最可能的原因研究了很久，其实在第一阶段排除干扰，确定不是各种简单错误才是重要的。
2. 调查病人的居住环境
这也是豪斯医生的老套路了，每集都会派两个小强到病人的住所去收集各种病人用过的东西来确定病人有没有可能接触了某些有害物质。程序员在debug之前也应该确定一下程序的执行环境有没有奇怪之处。很多时候程序的错误是因为没有考虑到某种特殊的外部条件，如果程序员可以在不同环境下跑一跑程序，也许很快就能发现错误的根源。
3. 发现病因，再治疗症状
记得豪斯医生中有一段戏，13怀疑病人得的是A或B病，这两种病都能用某药治疗，于是建议用该药。但是豪斯不同意，因为这样虽然治好了病人，但是“我们还是不知道她得了什么病”。
好吧，作为一个医生这样想真的很变态，但这是一个很好的debugging思想。debug的时候要找到的是 root cause，而不是仅仅把出错的症状绕过就了事了。一个程序员应该像推理小说中的名侦探一样，犯人，手法，证据，一样都不能少，否则是不能把众人召集起来做出破案宣言的。
4. 争分夺秒
豪斯面对的是一个随时都会咽气的病人，程序员面对的是一个随时可能推迟发布的产品。从这点来讲，程序员的压力并不比医生小。每个花了半年才调出的错误可能都伴随着一颗已经逐渐变得冰凉的客户的心。一个优秀的除错大师，不仅仅在于能调出多古怪刁钻的bug，也在于能多快的调出一个bug。对于小bug要秒杀，对于困难的bug则要有系统性的方法来应付。
5. 寻求灵感
Debug这件事，程序员的阅历越丰富，越容易想到错误的原因。平时应该多参加各种闲聊，也许某人对中东局势无意中的一句评论就能瞬间点醒梦中人。豪斯医生虽然有前面这些强大的工具，可是真正解谜那一瞬间都是在干别的事中得到的。所以平时多积攒些人品，关键时刻才有可能瞬间爆发。
