程序员是如何debug的呢？其实一个概念八个字就讲完了：单一变量，对照实验（controlled trial）。
「对照试验」是最最基础的科学实验方法之一，在初中生物课本里就已经被掰开揉碎详细教完了。按理说，任何一个读完高中的人都没理由不把这个科学思考方法吃到肚子里、融到血液中。可是环顾四周，却处处可见不知「对照试验」、「双盲测试」（多加了条件的随机对照试验）精神为何物的成年人：只消看看你周围还有多少中医粉就知道了……
不过请放心，暂时做不到逻辑思考也不是世界末日，还可以通过学习编程来拯救自己的脑回沟！
对于程序员来说，不管是多隐藏的bug，都可以顺着「对照试验」的思路来debug。
实际上有一种写程序的风格/方法就把「对照试验」的精神发挥到了极致，它被称为 Incremental Development（增量式开发）：
Incremental development:a program development plan intended to avoid debugging by adding and testing only a small amount of code at a time.
——Allen Downey (2015)
这种开发的思路就是每次只写一点点代码（即只增加一个确定的变量），测试没问题了，再进行下一步。
不太了解软件开发的读者可能会想问：除了每次往下写一点点，难道还有别的编程思路吗？
有！
比如，你可以把每个重要部分的基本思路框架都写个开头结尾，再分别往里填充具体细节；你还可以龙卷风般地先把能写的代码都写到底，最后再整体进行测试排除bug。
以上三种思路都是在开发单次版本的项目时的常见方法。如果把目光拉远，着眼于整个项目交付的流程安排，那「快速迭代」是公认的最有效率的开发模式——即，先快速完成一个可用版本，之后发现有问题或出现新需求再不断迭代推出新版本。
前者是个微观角度，后者则是宏观视角。
编程并不是什么特立独行的事，你肯定也能在解决其他具体任务过程中找到以上三种编程风格的影子——
比如，在看书这件事上就能很轻易地发现对应以上三种风格的读者：
小A们习惯从第一页读起，一个字一个字、一段一段、一页一页地，不搞懂前一句话什么意思，就绝不进行到下一句——你是「增量式阅读」的信徒！
小B们则偏好先读读目录，搞懂全书结构，每一章都挑开头结尾段浏览浏览，再开始细读具体内容——你是「框架式阅读」的实践者！
还有小C们，喜欢不管三七二十一，先龙卷风般把全书都粗读一遍，最后有疑问或有意犹未尽的地方再跳回去重新细读——你是「龙卷风式阅读」的追随者！
回到这篇短文的debug主题。不管你是哪种风格的程序员，最终排除所有干扰变量、捉住虫（bug）的结局一定是——
「排除一切不可能的，剩下的即使再不可能，也是真相。」
「Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.」
——福尔摩斯
∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷
以上这篇短文原型基于我之前写的一篇「观察日记」主题短文。然而上周读了安姐在她公众号「嘀嗒嘀嗒」上发表的《面对 bug 的正确姿势》（感兴趣戳文末“参考链接”）后，深感“姜必须是老的辣”！我看同一件事的角度远不如安姐成熟老练，当然身为高级工程师的安姐本来也是在实战上轻松碾压大部分菜鸟。受她文章的一点启发，我于是把自己原来的文章敲打修补了一遍，新版本就暂且是这样的了。
How to debug 肯定是个值得时新的话题，请容忍我目前浅显的思考水平，期待自己以后积累更多实战经验与反思。
在你面对代码里、生活中的 bug 时，有什么好的处理思路呢？欢迎在评论区分享给大家 :D
参考链接：https://mp.weixin.qq.com/s/yz4szTcJKiTbDQEsAnOFbA?
