工作烦恼与吐槽

       先说一下我自己吧,到目前为止已经工作5年了,目前在一家规模可以的公司中任职,我来这家公司之前是做qt桌面应用的,为了以后不被淘汰,我觉得应该深挖底层

所以到了这家公司维护qt底层库,我觉得这是一个不错的工作,因为我可以远离无聊的业务代码和业务需求,转而去学习一下底层库代码

       不过现在我遇到了问题,公司的应用是用qt开发的,但是出了崩溃、闪退问题,他们看看堆栈,发现是崩溃在Qt库里面就直接把bug转过来了,刚开始我还有精力看一下

但是推给我的问题越来越多,问题堆积的越来越多,导致我很难静下心去研究每个问题

        更难受的是,有的问题排查到最后其实就是业务代码的问题,我两三天找到问题的根源,和应用同步一下,人家半天就改完了,我也只算参与排查,不能算是修改

除了崩溃、闪退这种极端的问题,还有一些功能性的问题,应用实现的功能有问题,也会转到我这里,这都极大的浪费了我的精力

我自己最近复盘了一下,得出了以下结论

            1. 我的这个岗位可能就是干这个活的,我以前所在的公司都没有维护qt库的岗位,这家公司有这个岗位,那么默认应用只管使用qt,qt有问题就找我,我也应该解决(有点PUA自己了哈)2. 应用那边就是偷懒,不愿意尽力去排查,毕竟每个人都愿意省事3. 我现在也没有很好的方法去判断应用推给我的问题是不是qt底层库的问题(我大概率认为不是qt库的问题,qt不能这么烂)我没有明确的证据也不好推回去

分析完之后,我发现我自己也就能把第三点完善一下,公司和其他同事,我也不能去要求什么,所以我梳理了一个排查步骤

崩溃、闪退问题排查

1. 在确认是qt库导致的问题之前,不接受指派的bug

2. 让应用负责人提供崩溃堆栈信息,这里要注意有的人为了省事直接就用gdb看release版本的堆栈,这样的堆栈信息什么都没有,不会展现应用上的细节,这也是很多人一看堆栈,没看到应用的崩溃就给底层的原因,所以要和应用负责人确认是不是按照以下步骤获取的崩溃堆栈信息

            采集堆栈信息的步骤:(1) 安装应用对应的debug包和qt对应版本的debug包(2) 再次复现一次问题(3) 使用gdb查看新生成的堆栈信息

一些非主产品线上会找不到应用对应的debug包,这时候需要在复现问题的电脑上搭建开发环境去编译debug版本

我目前处理的两个崩溃问题,最后都是在安装debug包后,从崩溃堆栈上看到崩溃位置是在应用业务代码上,这是目前是最容易划分崩溃责任的方式了

3. 应用负责人按照正确的步骤提供堆栈信息,如果堆栈信息中有明确的qt代码崩溃位置,则接收bug,反之,qt框架可以协助排查,视情况决定是否接受指派bug

4. 在排查问题时,要拉测试和应用负责人进群沟通,避免做传话筒

5. 在要完全投入去排查问题前,要确认如下信息

        (1) 通过堆栈信息已经无法看出崩溃的具体位置(2) 确认测试负责人 确认应用负责人(3) a.确认电脑硬件 b.确认操作系统版本(build id) c.确认应用版本 d.确认qt版本(4) 确认问题的现象,测试提供问题现象视频(5) 确认问题是否必现,确认问题复现的手法,测试应提供高复现率的操作手法

6. 问题排查阻塞,无法继续进行的,要及时向上汇报

 

功能性问题排查

1. 在确认是qt功能问题之前,不接受指派的bug

2. 应用负责人应提供一份能复现功能问题的最小demo,这样就不用梳理应用的业务逻辑

3. 应用版本不变,更换qt版本比较

        例如,目前的版本是qt0.3版本有问题,那么可以将qt更换到qt0.2版本再测试,如果还有功能问题大概率就是qt的问题了

总结

        虽然我自己梳理了一些排查步骤,不过还是很难落地。本质上还是没有一个能快速划分问题责任的方式,有些问题看起来是qt问题而且也不好推给应用,我也不想去为了一个问题归属扯皮(可能再干烦了就会去扯皮了)

        不知道我以上的思考是否正确,请看到这篇文章的大佬提供点建议,谢谢