码农的世界是确定性的。用确定的方案去实现确定的功能，确定的逻辑产生确定的结果，如果出现了错误(俗称bug)，那么一定能够通过分析找到确定的原因(俗称root cause)。即使用到随机函数，随机因子也是确定的。
但是码农的世界里也有不确定性。比如常见的一个情况，产品在用户那出问题了，拿到实验室，问题却始终无法复现。这个时候就只能解释为技术之外的原因了，比如说用户环境很诡异啊，太阳黑子活动异常啊。还有一个常见的解释，人品问题。如果满足同样的条件，在别人那没有问题，到你这就始终有问题，那就只能怀疑是你的人品问题了。
我最近就遇到了这样的人品问题。
测试那出现了一个bug，我按照复现条件，测试了一天都没有复现问题，但是在同事那却很快就复现了，我不服，让同事在我的环境上测试，结果第一次就复现了。我无语，回去自己接着复现，心想概率小多试几次总能复现吧。结果到了第二天，我依然不能复现。同事却又是一次就复现了，看操作步骤、操作命令都一样啊，为啥到我这就复现不了呢。同事也解释不了，最终一致认为，这是人品问题。我很沮丧，心想我人品大概真的不好。
但是，从标题看，你们也知道这背后一定有不可告人的秘密。
中午吃完饭回来，我重新复现，并且仔细观察每个步骤的现象，观察到有个操作每次都会发送几个报文，很可疑，于是抓包分析，分析清楚这是一种主动关闭TCP连接的报文，我不复现的原因找到啦。那么同事为什么在我的环境下就能复现问题呢，再去跟同事分析，原来同事在同样的命令下加了一个参数，这个参数会导致不发送这种报文。真相大白，不是我的人品问题!
细细想来，这背后其实是技术问题。不了解报文交互的流程，也没能早点观察到这个报文以及操作的细微差别。这就是技术有问题，得治!
码农伙伴们，上面的这个例子很常见吧，它虽然不能证明我们的人品没问题，但是至少证明了不是人品问题。这个世界是不确定的，但是技术的世界里却更多的是确定性。如果出现不能解释的问题，静下心，细心以及耐心的找到真正的root cause。还有更重要的，扎扎实实的，练好内功吧。
