小方

今天是所在产品线发布的前夕，在手动的测试过程中突然遇到了一些奇怪的bug。表现出来的现象是源数据段为320W数据，但流出来的数据时而340多W，时而640W。

瞬间怀疑是race condition相关的问题。在产品界面上打开了运行的日志窗口，大致扫了几眼，并没有发现错误日志，觉得有点小方，凭借以往排查这类bug的经验，觉得一场恶战在即。嘟囔了几句，立刻在脑海里思索可能出问题的地方。

产品线的老司机给了一个建议——查看上游组件A的输出数据，发现并无问题。立刻将问题缩小到了下游的B组件。而一个同事上去grep了一把日志，发现了异常。而根据异常信息，成功找到了问题所在。

我瞬间觉得有点惭愧——我把简单的事想复杂了。想想原因，大概有这么几点：

1. 在之前对两个组件的测试中顺风顺水（几乎没什么大bug,小bug秒解）。这让我有点“膨胀”
2. 查看组件的整体日志成本略高，需要打开一个网页，查询组件所在的host(这是个分布式系统)，再登上去。因此我经常在日志窗口里看日志。
3. 目前的日志窗口对于开发者来说不太好用，必须一直盯着or不停的刷新来判断当前组件的大致状态。这导致 “膨胀”的我在查看日志窗口的时候错过了错误堆栈。
4. 我对我负责的模块了解还不够透彻——它的鲁棒性并不是我想象中那么的好。

既然想清了原因，便可以想想以后该怎么做来避免这些问题：

1. 多写测试——在代码各个地方（尤其是与外部应用交互的地方）引起异常。来确认系统的鲁棒性。并增强对组件的理解。
2. 引入一些日志系统来避免查看日志麻烦的问题。之后Host一旦多起来，debug就是一场灾难。
3. 在引入日志系统之前，在debug时要勤看日志。
4. 对目前两个组件进行较为透彻的源码分析，并输出成文档，以此来加强对它的理解。和产品线的同学一起学习改进它。这个事情这礼拜我已经在做起来了，不过还没做完，不然今天也不会这么方了。