编程中如何跟人描述Bug
早前有句话很火:"明白很多道理,依然过不好这一生". 上个月看到一个新闻:一个宣传诈骗的人,被人骗了.
听别人讲故事和自己去经历这事件区别很大, 本文用来记录
圈子里有篇经典的文章叫提问的智慧,
如果你遇到了Bug,这时会怎么做:
- 看现象:推测哪里/哪一阶段出了问题
- Google:搜索什么关键词
- 看文档:(不熟悉的东西就会去看文档,弄清底下干了什么)
- 提问:问有经验的人
这里主要讨论提问:如何跟人去描述问题
描述问题症状而非你的猜测/结论
有次, 同事调用我写的接口,然后跑来告诉我, 是啥啥啥我哪里有问题(直接告诉我他的结论), 然后我就沿着他说的结论去追踪, 结果, 被带到坑里去了, 最后导致浪费了些不必要的时间. 在新闻里有一个很熟悉的场景, 即便"犯人"被抓到了,即便是在法官宣判前已经确认事实了.都会称他为犯罪嫌疑人. 如果你说的结论是对的还好,如果是错误的就会被坑
正确的流程:
- 表明意图: 在做一个什么功能? 调试什么东西?
- 你是如何做的,用到哪些技术,模块,整个流程是怎么样的?
- 哪个地方不符合预期? 正常是什么样子? 现在出问题是什么样子?
- 分析数据或是执行流程,可以在哪一阶段出问题了,推测是由什么引起的
在谈问题Bug
我想说每一个bug都要去珍惜, 它是你一次探索知识的机会, 是一次加深对技术理解的机会, 是一次去理解它内部是如何工作的机会, 知道了它内部是如何工作的之后, 你对技术的把控度会越来越高; 理解他内部的处理策略之后, 以后有类似的应用场景,可以用上,这叫积累.
最后,最重要的:你的每一次对待问题的处理方式,塑造了你会成为一个什么样的人