自行车维修与软件debug

今天我把自行车送到迪卡侬维修,维修的过程很有意思,让我想到了软件开发中的debug。

bug是指计算机程序的故障,debug是指修复程序中的故障。

我的自行车出现的问题很好描述,就是在蹬踏时,每次踩踏一周,就会出现一个金属摩擦噪音。这是自行车的经典故障,统称「异响」。

迪卡侬的店员接过我的车,装到维修台上,转动没几下,也听出了噪音。他说,这应该是中轴问题,这类中轴的通病。他说这话的时候,面色还有点凝重。听我说这车刚买两周,就更显的沉重了。他说,他会调货这个零件,但是周期可能很长,也不一定是中轴的问题,不过请放心,有问题就按质保来,先加个微信吧。

听他这么一说,我是感觉有点倒霉,咋就碰上个这小毛病呢?其实本来我还不觉得这噪音有多大,今天来检查以后,在这车没修好前,我再出去骑车的时候,肯定老得想着这事。

不过,在离开之前,我还是有点不甘心,或者说就是好奇,到底中轴出问题是个什么细节。我就蹲在车旁边,自己转车后轮,听噪音的规律,一边听一边看…看着看着,竟然发现了故障的原因!其实特别简单,就是有一个钢丝线头有点长,和脚踏板的那个轴柄产生了摩擦,所以才会每个踩踏周期都出现一次噪音。尝试把线头往里折了一下…问题消除了。

图中央的线头就是故障原因

总而言之,这是一个本来原因特别简单,解决起来也特别简单的问题,险些发展成了周期长,成本重的维修活动。

迪卡侬自行车小哥,他们的维修技术肯定是很专业的,那么为什么会出现这个低级失误呢?以下是我的猜测。

\1. 他们都太忙了。

\2. 我对他产生了误导。

\3. 维修者已有的经验。

首先,他们确实很忙碌。西直门这家迪卡侬,周末时的自行车维修区都很忙,主要是来买车和修车的小朋友很多。小哥在修我的车的时候,他手里还排着两个童车要拼装(顾客在等)。在忙碌中,可能注意力有点不够用了,没能做全面的检查。

其次,我回想我们的对话过程,我有可能对小哥产生了误导。他最开始说这可能是中轴问题,我一下就接了往下说中轴的事,问了问中轴具体是咋回事之类的话题,他也顺着中轴的思路往下看。也许他当时还有排查其他故障原因的计划,但由于我们在「中轴」这个话题上往下进行了好几步,就回不到那个决策程度比较浅的十字路口,而认定了中轴就是故障原因了。

再有,小哥说了句「这是这类中轴的通病」。他对自行车显然很有研究,我这类公路车又不是迪卡侬的最主流销售款,所以当他看到一个少见车型的少见故障,这个故障又正好能和他对这种车型的中轴型号的认识联系起来,所以做出这个判断看似很合理。

以上就是我对这个误判的猜测。其实我在想,这和软件开发中的debug真的挺像的。

我以前踩过很多次这样的坑:在debug时,对某种猜测的原因往下钻的太多,殊不知真正的故障原因,本可以更快、更轻松地排查出来。用计算机的话说就是,用深度优先遍历走的太远,而忘记了应该先快速做一遍广度优先遍历。

更具体的说,我应当先充分地观察,先全面地收集整体的信息,先尝试做最简单的修复尝试。比如有一次我为了解决一个Linux的环境故障,吭哧吭哧搞了半天也未能解决,最后发现只要重启一次服务器就修复了。而且,那个服务器只是我个人的服务器,没有任何重启成本。

再举个例子,我有一个日常维护的后台数据处理程序,这个程序有内存泄漏的问题,内存会越吃越多。如果我要解决这个问题时,先从jvm调优开始,我不仅得学好多东西,可能调出来的效果也不好,毕竟地球人都知道jvm调优不是门简单学问。也许更好的方法是,直接找到程序中造成内存增长的语句,看看有没有什么办法能避免它(最后的确也是这样解决的,非常快速)。甚至,由于这个程序是无状态的,我甚至可以每天半夜重启一下它,也能解决内存泄漏的问题,虽然有点将就,但可能这就是工程吧。

如果家里有腾达路由器,可以看下,高级设置里有一项「每天定时重启」,时间就是半夜。

我希望自己能够记住这一点:在开始尝试任何需要耗费一定时间的debug时,要先确保所有简单的方案都被考虑过,或被尝试过了。

前有《禅与摩托车维修艺术》,看来自行车维修也能给人一些启发。

===================

2020.06.07

于西土城公园