你真的会修bug吗

2021/8/29 development

dont know why

一个软件开发工程师水平怎么样,看看他是怎么修 bug 就知道了。最近,我们团队里要求大家在修 bug 的时候在 MR 描述中回答 7 个问题,简称 Bug7 问。这里都列出来,欢迎大家讨论。

# bug 调查

除了 chrome 开发者工具,你还会使用其他什么调试工具和方法吗?

你会去看错误信息日志吗?会移动端真机调试吗?会配置代理吗?会抓包吗?会脱离浏览器环境发送验证请求吗?

即使是 chrome 开发者工具,你又使用过哪些功能呢?能够在没有 sourcemap 的情况下去代码中定位问题吗?会根据点击事件定位代码位置吗?会打断点并且修改变量的值吗?知道 profiling 的各项指标是什么含义吗?看过堆快照里面都是什么东西吗?

能够在本地模拟线上环境吗?能够在不了解源代码的情况下定位白屏问题吗?能够模拟特定用户的登录吗?

# 确定修复方案

你知道这个 bug 引入的根本原因是什么吗?

你知道当初是谁在什么时候引入的这个 bug 吗?当初为什么会写成这样呢?

你思考过哪些修复方案?为什么选择这一种?

你改动了公共的方法吗?改动了公共组件吗?你思考过修复方案的影响范围是什么吗?

你确定你的改动方案一定可以解决这个问题吗?

你思考过这个 bug 会不会还出现在其他地方吗?

你思考过这个 bug 是否值得分享给其他人吗?

# 三个阶段

  1. 初级阶段:自己都不知道在做什么

不知道到底是什么原因引起的,看上去是这里出了点问题,那就这里改改,然后验证一下,好像没问题了,哦?哪里好像又坏了,再改改,好像都没问题了,嗯 bug 修好了,上线吧。

初级阶段可能都不一定能保证 bug 真的被解决了,属于碰运气,可能解决了,可能没解决,还可能引发更大的 bug。

  1. 中级阶段:就是修 bug 而已

知道 bug 的根本原因是什么,经过个人的思考和斟酌,在若干方案中选择了一个,修复完本地自测没问题,上线,问题解决!

中级阶段,可以基本保证 bug 确实是被解决了,而且修 bug 的效率很快方案也可维护,但是呢,也就仅限于此了(对比高级阶段)。

  1. 高级阶段:不仅仅只是修 bug

知道 bug 的根本原因是什么,此外还通过 git blame 等方式追本溯源到最初引入的时刻,以及当时做什么引入的,尝试思考和理解当时写下这段代码的人是怎么考虑的。确实是漏考虑了?还是有一些特殊原因特意写成这样?在修复方案上反复斟酌,不但得把 bug 修复了,而且在写法上可以避免相同的问题发生,同时对代码的侵入性尽量小回归范围尽量可控。修复完成后在项目中又搜一搜看看还有没有其他类似的可能出 bug 的地方,如果有,则看情况一并修复还是记录优化任务单独再修。不但本地自测,还会去测试环境验证,最后上线了总觉得不放心还得再去线上环境亲自验证一下。典型的问题沉淀到文档中,分享给团队其他人,帮助大家一起进步。

可以看到,高级阶段是经历了大量的思考过程,不但完成了 bug 的修复,还同时加固了项目的整体质量,沉淀了文档对外输出分享,对个人而言也是一种经验的积累,修一个 bug 产生的个人思考和经验积累鼎别人修 10 个。

你在什么阶段呢?

Designed by Lishunyang | 京ICP备20009157号 | All right reserved