没细看

昨日在查一个bug的时候,发现了另一个bug。这个bug让我疏忽了上一个bug。

上一个bug假如发生,会通过log的形式输出到特定文件夹内,并且会命名为指定的名称。

但上一个bug发生了,这个指定名称的log却不存在。为什么呢?我百思不得其解。

我在发生bug的前一刻,将所有log全部清除,然后触发bug,有一些log生成了。

我打开全部log,发现某一个不应该存在的log,里面居然含有这个bug的信息。

bug解决了,新bug出现。也就是说,按照指定名称输出的log,名字是另一个名字。

我找到log列表和代码中的枚举值,将两者比较,发现两者不一致。

有个别的log枚举值不存在,而列表存在;要不就是枚举值不存在,列表也不存在。

这种情况一定是两者不匹配造成的日志输出错位。只要将两者一一比对,删掉log列表中存在而在枚举值中不存在的log名称即可。

我查看log的底层代码,想看看能否从底层解决这一问题,但不知是谁写的底层代码,内部盘综复杂,很难查。

看着看着有些眼花,我也就不再继续了。

我找到负责人,向她说明了这一情况,希望由我解决这一问题。

但她说:“这部分内容枚举值是写死的数字,log是按照数字对应的log名来输出,不应该发生这种情况,这是为什么?问我有没有看底层怎么写的?”

我说:“没细看。”

于是她说她自己先看看,打算从底层看看能否解决这一问题。

我有些后悔,因为我没能找到症结所在。一句“没细看”,是偷懒的表现,是不负责任的表现。我只想解决问题,没考虑去发现问题背后的问题,我这是“知其然不知其所以然”。这次我能解决问题,或许是巧合,下次还有这种事,用笨办法不一定就能解决问题,而且我这样做了,或许其他人不小心又会触发这个问题,所以要找到症结所在,对症下药,才是良策

负责人因为别的事情,暂时无暇跟进这个问题,最终还是让我来解决。一会我就去解决,从根上解决

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章