自行车维修与软件debug
今天我把自行车送到迪卡侬维修，维修的过程很有意思，让我想到了软件开发中的debug。
bug是指计算机程序的故障，debug是指修复程序中的故障。
我的自行车出现的问题很好描述，就是在蹬踏时，每次踩踏一周，就会出现一个金属摩擦噪音。这是自行车的经典故障，统称「异响」。
迪卡侬的店员接过我的车，装到维修台上，转动没几下，也听出了噪音。他说，这应该是中轴问题，这类中轴的通病。他说这话的时候，面色还有点凝重。听我说这车刚买两周，就更显的沉重了。他说，他会调货这个零件，但是周期可能很长，也不一定是中轴的问题，不过请放心，有问题就按质保来，先加个微信吧。
听他这么一说，我是感觉有点倒霉，咋就碰上个这小毛病呢？其实本来我还不觉得这噪音有多大，今天来检查以后，在这车没修好前，我再出去骑车的时候，肯定老得想着这事。
不过，在离开之前，我还是有点不甘心，或者说就是好奇，到底中轴出问题是个什么细节。我就蹲在车旁边，自己转车后轮，听噪音的规律，一边听一边看…看着看着，竟然发现了故障的原因！其实特别简单，就是有一个钢丝线头有点长，和脚踏板的那个轴柄产生了摩擦，所以才会每个踩踏周期都出现一次噪音。尝试把线头往里折了一下…问题消除了。
图中央的线头就是故障原因
总而言之，这是一个本来原因特别简单，解决起来也特别简单的问题，险些发展成了周期长，成本重的维修活动。
迪卡侬自行车小哥，他们的维修技术肯定是很专业的，那么为什么会出现这个低级失误呢？以下是我的猜测。
他们都太忙了。
我对他产生了误导。
维修者已有的经验。
首先，他们确实很忙碌。西直门这家迪卡侬，周末时的自行车维修区都很忙，主要是来买车和修车的小朋友很多。小哥在修我的车的时候，他手里还排着两个童车要拼装（顾客在等）。在忙碌中，可能注意力有点不够用了，没能做全面的检查。
其次，我回想我们的对话过程，我有可能对小哥产生了误导。他最开始说这可能是中轴问题，我一下就接了往下说中轴的事，问了问中轴具体是咋回事之类的话题，他也顺着中轴的思路往下看。也许他当时还有排查其他故障原因的计划，但由于我们在「中轴」这个话题上往下进行了好几步，就回不到那个决策程度比较浅的十字路口，而认定了中轴就是故障原因了。
再有，小哥说了句「这是这类中轴的通病」。他对自行车显然很有研究，我这类公路车又不是迪卡侬的最主流销售款，所以当他看到一个少见车型的少见故障，这个故障又正好能和他对这种车型的中轴型号的认识联系起来，所以做出这个判断看似很合理。
以上就是我对这个误判的猜测。其实我在想，这和软件开发中的debug真的挺像的。
我以前踩过很多次这样的坑：在debug时，对某种猜测的原因往下钻的太多，殊不知真正的故障原因，本可以更快、更轻松地排查出来。用计算机的话说就是，用深度优先遍历走的太远，而忘记了应该先快速做一遍广度优先遍历。
更具体的说，我应当先充分地观察，先全面地收集整体的信息，先尝试做最简单的修复尝试。比如有一次我为了解决一个Linux的环境故障，吭哧吭哧搞了半天也未能解决，最后发现只要重启一次服务器就修复了。而且，那个服务器只是我个人的服务器，没有任何重启成本。
再举个例子，我有一个日常维护的后台数据处理程序，这个程序有内存泄漏的问题，内存会越吃越多。如果我要解决这个问题时，先从jvm调优开始，我不仅得学好多东西，可能调出来的效果也不好，毕竟地球人都知道jvm调优不是门简单学问。也许更好的方法是，直接找到程序中造成内存增长的语句，看看有没有什么办法能避免它（最后的确也是这样解决的，非常快速）。甚至，由于这个程序是无状态的，我甚至可以每天半夜重启一下它，也能解决内存泄漏的问题，虽然有点将就，但可能这就是工程吧。
如果家里有腾达路由器，可以看下，高级设置里有一项「每天定时重启」，时间就是半夜。
我希望自己能够记住这一点：在开始尝试任何需要耗费一定时间的debug时，要先确保所有简单的方案都被考虑过，或被尝试过了。
前有《禅与摩托车维修艺术》，看来自行车维修也能给人一些启发。
===================
2020.06.07
于西土城公园