Debug 是门艺术

最近想结合发生在身边码农身上的一些小故事，尝试表达一个观点“Coding 是门技术，Debug 是门艺术”。

上期的分享《Coding 是门技术》主要通过引入身边 Code farmer 撸码的一些真实故事，掰扯了一下开发规范以及重构可以改变代码的设计的理念，并且文末我又尝试总结了，人人皆知的一个看似专业而又非专业的撸码套路（一篇流水账，而却忘了升华，我就喜欢这么自嘲）。

但是，作为码农，撸码肯定是日常必须，毕竟要靠撸码吃饭，但是为了能更好的保住饭碗，Debug 则显得尤为重要，因为鲁迅先生说过「程序猿 20% 的时间在 Coding，80% 的时间在 Debug」鲁迅先生又说「他从来没说过」。

好了，话不多说，请扶稳坐好，我们正式来聊聊 Debug 这门玄幻的艺术。

01. Debug 的精髓

---

Debug 的艺术，我简单归纳为 「Debug 三步曲」。

第一步：FindBug。

无论遇到任何问题，Debug 时一定要清晰牢记，通过剥丝抽茧的方式，努力逐步缩小范围，最终锁定 Bug 的藏身之处。

第二步：FixBug。

依据撸码经验，经过多轮的修复-验证-修复-验证，最终让Bug扼杀于无形之中。

（图片来源于网络）

第三步：RecordBug。

为了保证 Bug 不二过，当然一定要把 Bug 的原因、现象、解决方式记录在案，这样就以防其他老铁再入坑。

好了，接下来就一起看看，发生在身边高鸡攻城狮身上的一些有趣的 Debug。

02. Debug 的故事

---

故事一：运维小哥配置的 crontab 引发的 DeBug。

经常撸码的老铁都清楚，系统一般白天疯狂吸引客户，也就是疯狂吸金，晚上一般会启动 N 多个批处理，在运维小哥那儿也不例外，配置很多释放资源、机器巡检等一系列的 crontab 任务。

近期团队让运维小哥帮忙搞了一台新机器，上面部署了新服务，并且配置了一个每天凌晨 1 点 10 分定时执行清洗数据的任务。

10 1 * * * /app/clear.sh >> /app/log/clear.log

理想很丰满，现实却很骨感。每天凌晨 1 点定时任务却迟迟未执行，于是就开启了 Debug 的过程。

Step 01：FindBug。

核心原则「努力缩小 Bug 范围」。

• 首先排除常规性的配置错误，例如目录、脚本名称配置错误；

• 然后排除脚本是否有执行权限，通过 ls 命令，发现脚本执行权限正常，而且手动执行脚本也没毛病；

• 接着重新调整 crontab 的执行时间，确认是否会执行，发现确实到点了不执行，不过却有一个很诡异的一个现象，那就是有一个每两分钟执行一次的测试脚本 test.sh 却能够正常执行；

• 大胆猜测，由于每两分钟的任务正常执行，有小时配置的任务却不执行，此时不得不怀疑是机器的时间导致的？！运维小哥坚信时区没问题，因为近期刚调整过，但是处于 Debug 环节，还是需要通过命令再次确认时区信息。

  

如上图示意，发现时区配置确实没啥毛病。那哪里会出现问题呢？会不会是 crontab 服务启动的时候，时间还没有调整呢，导致 crontab 的时间与当前的时间不一致？

眼尖的同学，此时会发现，时区配置的确晚于 crond 启动时间。

Step 02：FixBug。

核心原则「扼杀 Bug 于无形」。

由于时区配置，但是没有重启 crontab 服务导致，那就重启 crond 服务呗，重启完，时间确实对了，效果如下。

修改完成之后，经测试完全 OK。目前再去看线上清理的批处理，一切跑的又是那么的完美。

Step 03：RecordBug。

核心原则「每一个 Bug 都载入史册」。

故事二：攻城狮玄幻的 rz 命令上传的奇葩 DeBug。

不知道大家平时喜欢用什么登录线上服务器，身边攻城狮用的最多的莫过于 SecureCRT，用这款工具日常连服务器、查日志不再话下，不过用的偏多的就是用 rz 命令、sz 命令。

假如要向服务器上传文件，用 rz 命令就可以轻松搞定；假如要下载文件，用 sz 命令也可以轻松搞定（没用过的老铁建议尝试一下，绝对会让你 WOW！）。

不过最近身边攻城狮光头强，倒是在用 rz 命令上传文件时，栽了个大跟头，先抛个情景对话，让我们感受一下光头强那种百思不得解的痛苦。

眼尖的同学会发现主要问题，在光头强同学输入 rz 命令后，总是提示如下信息。

rz waiting to receive. Starting zmodem transfer.  Press Ctrl+C to cancel.

然后就没有然后啦，汗颜。正常情况下输入完命令，会提示上传文件窗口，然后选择要上传的文件，就应该上传成功了。

何解？面对工具性的 Bug，无需花太多时间在 FindBug 上，直接可以跳到 FixBug 环节，建议直接卸掉重装就好了，但是令人匪夷所思的是重装了还是不好使啊，而且光头强还没有其它 ftp 上传工具。

此时脑海中应该弥补一个场景：紧急部署线上应用，但是就你一个人有登录堡垒机的权限，而你又无法进行上传文件，那么此情此景，只能用下面这张图来形容。

面对这种比较玄幻的问题，只能另辟蹊径，建议光头强老弟直接拖住上传的文件到 SecureCRT，未成想确实好使！

面对这种玄幻的奇葩问题，也只能奇葩对待啦。

03. Debug 的武器

---

武器推荐系列一：用 Debug 来发现「什么是别人家的代码？」

为什么别人家的代码，不但写的好，而且Bug 少，最重要的是从来没因为 Bug 扣过绩效，莫非有什么奇招。

撸码久了就知道了，Coding 是门技术，但是撸码也是有套路的，很多攻城狮在撸码完成之后，喜欢采用 FindBugs 工具插件，找找有没有潜在的代码风险。

不过也有很多老铁，撸码完成之后，喜欢用 sonarQube 来提升提升代码的逼格，随便贴一效果图。

上期分享我们提到了《阿里巴巴Java开发手册 v666.pdf》，其实也有一款把阿里巴巴 Java 开发手册中的规约的插件，可以在你撸码的时候，自动帮你检测是否符合规范（So，牛掰），该插件已经在 Github 上开源。

https://github.com/alibaba/p3c

以上几款让 Bug 扼杀在摇篮里的武器，感兴趣的老铁，可以亲自体验一下。

武器推荐系列二：线上甩锅的 DeBug。

久入职场，迟早会经历各种奇葩的锅。锅该背的背，不该的背坚决不背，要有自己的态度。但是面对不该你背的大黑锅，如果你却拿不出证据，只能哑巴吃黄连，有苦也说不出。

例如你刚上线了应用，服务器 cpu 或者内存就疯狂报警，此时微信群里直接把锅扣你头上，你该怎么应对？

那肯定是沉着冷静，并按照之前的一篇分享《这部技术葵花宝典真的很硬核》逐步去排查解决。

另外面对线上重要模块却没有任何日志输出，排查无从下手的情形时，不妨在关键位置打印日志，以便尽快定位问题，快速止损。

04. Debug 的态度

---

有 Bug 不可怕，Debug 是我们前行的催化剂。

面对 Bug 要沉着冷静，不要像生吞蜈蚣一样，百爪挠心。

Debug 要剥丝抽茧，努力缩小范围，找到 Bug 点；通过日常的经验积累，解决 Bug 于无形之中；针对 Fix 的 Bug一定要载入史册，因为它绝对是一笔财富。

再抛几个玄幻的问题 Debug 场景，结束咱们的分享。

• 为什么你一来我这儿就好了？刚刚怎么调试都不行？！

  哎，Debug 是玄学艺术！

• 为什么你这么一操作就好了？刚刚我也是这么操作的啊？！

  哎，Debug 是玄学艺术！

• 线上部署了 4 台服务，配置都一样，项目 war 包也一样，为什么偏偏只有这一台有问题？几经排查无解，而且换一台机器又恢复了平静。

  哎，Debug 是玄学艺术！

好了，今天的分享，到这就结束啦，希望你们能够喜欢。