40岁程序员谈修bug的心态问题

【CSDN 编者按】于程序员而言，如果说写代码是一种能力的体现，那么解决问题的能力也同等重要，排查问题的能力或许能决定你的职业生涯走的有多远。因此，常有人戏言，程序员不是写代码，而是在写 bug。本文作者是一名 40 来岁的 Linux 内核工程师，他基于自己多年的编码经验，谈谈程序员面对 Bug 时，该如何思考。

作者 | 宋宝华     责编 | 梦依丹

出品 | CSDN（ID：CSDNnews）

笔者是一个老码农，早已年逾 40，目前仍然奋战在一线写代码、修 bug，并没有出现传说中的 35 岁危机。工作这么多年，方方面面的 bug 也接触了不少，想作为一个老码农分享关于修 bug 的心态问题。

首先作为一个程序员，只要是写代码，肯定是会产生 bug，除非这个人不写代码。所以，这一个基本的常识我们得心平气和的接受。要是有个人吹牛说自己写的代码没 bug，那一定是个骗子或者自大狂。但是这并不等于 bug 越多，就越牛逼，我们在编程的时候，肯定是要采取各种手段避免 bug 的发生。比如尤其要注意：

1、多线程、多进程并发访问风险；

2、边界条件处理；

3、遗漏的分支处理等防御性编程的基本思想。

在修复 bug 过程中，最重要的一个心态就是要切莫急躁，急躁是修复不了 bug 的。有的同学，领导进度催促的紧，他就东改一行，西改一行，企图碰运气把这个 bug 修掉。笔者工作这么多年，基本从来没碰到过这样的运气。

代码是这个世界最符合逻辑的东西，反逻辑的运气是不会出现的。越是难修的 bug，越是进度紧张的 bug，越是要心态平静。反复复盘代码逻辑，复盘自身的模块与其他模块的关系，复盘全局的多线程数据访问、时序逻辑。简单来说，对自身关注的代码以及你的代码与其他代码的逻辑关系梳理地越清楚，修复这个 bug 越成为可能。所以实在没思路了，怎么办？复盘逻辑！继续没思路了，怎么办？复盘逻辑。

我印象比较深刻的，之前在修复 wayland 的 client UI 和 server weston 之间通信的逻辑时，crash 的是 Qt App，但是实际的问题是出在 weston 和 app 之间通信的 wayland message 时序上，这个时候唯一的办法，就是理清 wayland 的协议，什么时候 client 和 server 应该发什么样的消息，什么样的消息导致窗口的 destroy 等，只能静下来来，反复分析。一条条看捕获的 client 和 server 之间的 wayland socket 消息，对照协议分析 client 和 server 进程之间的时序是否紊乱了。没有其他的办法。

退一万步讲，哪怕一个人真地瞎试把 bug 侥幸“修复”了，对个人的成长又有什么帮助呢?我们提炼了什么规律呢？理清了什么逻辑呢？自己能说的清楚为啥修复了吗？这样的蛮干是不会成长的。

在修复 bug 的过程中，不妨尝试 refresh 一下自己的大脑。有时候脑袋麻了，思路就会短路了。不如出去呼吸五分钟新鲜空气，看似浪费了五分钟，实则很可能在这五分钟里面，获得了一个思路。我个人经常碰到的情况是，在电脑面前坐麻了，心情也比较焦急，因为急着修 bug 啊。但是，娃放学到点了，我不得不出去接个娃，十来分钟路上，我发现这个 bug 我回来就可以修复了。所以，有时候，慢就是快。看似浪费了十分钟接娃，实则这十分钟的新鲜空气清醒了大脑，所以修复这个 bug 的贡献可能得算到娃的头上。

写代码的时候，不妨多加一些断言/BUG_ON 之类，在不确定的位置，留下一下打印。代码的世界充满了神奇，你觉得走到某个位置的时候，a 必然是等于 1 了，但是代码跑起来偏偏就等于 2。为啥呢？因为是代码就有 bug 啊，是 bug让它不等于 1 的。那么我们可以尝试加一个 BUG_ON（a!=1）。任何的 bug，都是出现地位置越早，越好修的。BUG 遵循“早死早超生”的规律，如果你在 a 处犯错了，死在了 b 处、c 处、d 处，显然你比较难追溯到 a 处，但是如果你在 a 处就提前侦测到了潜在的问题，则主动降低了修复这个 bug 的难度。尤其是产品上线后，甚至会出现实验室反复测试都无法复现的 bug，这些异常点增加的 BUG_ON、打印之类，都可以帮忙提示修复的方向。

修复 bug，需要建立业务领域知识的广度和深度。作为一个 Linux 内核工程师，比如改了内存管理、page fault、swap 等的代码，看似仅改了一个模块的很少一部分代码，但是由于这个代码太底层，它可能和很多其他的内核组件比如调度、文件系统、VFS、page cache 等都有千丝万缕的联系，这个时候，没有对内核的广度和深度的理解，是很难修复 bug 的。所以，我们千万不要小看了修复 bug 这个事情本身，同样的 bug 有的人弄一个月都不知所措，有的人两天就解决了。你觉得差的这 28 天原因是啥？无他，懂还是不懂业务知识，而不是编程语言本身。

所以，对 C、C++、Java 等语言的掌握度是绝对拉不开程序员距离的，能拉开程序员距离的是对编程语言施加的业务的掌握度。语言是个最基本的东西，你比如每个美国人都会说英语，但是每个美国人的业务水平都不一样，有人 0 元购，有人乔布斯。作为一个程序员，你能拿出来炫耀说自己 C 语言炉火纯青吗？这个没用的，就跟一个美国人说自己英语说的好一个道理，没意义。

本文文字及图片出自 CSDN