MSFT：我们组的工作日常是听写debug command

这类工作英语也叫“bring up”，我不知道这是一个term还是惯用语，具体就是n个人加入一个meeting，一个人share screen，一堆人看着，然后一个大佬报个command，然后share屏幕的人敲，目标是让一个os/driver/azure的一个组件 work。

有时候bug的表现就是不work，但是为啥不work非常难triage，需要硬件软件各种模块的各种senior/principal进来说话。比如我们发现一个bug，在重启49次的情况下系统崩溃。为了搞清楚为什么，就先A share screen，然后一堆人围着看，然后B说能不能执行一个command打印某个register的值，我报你写，然后B就一个字符一个字符读，A就跟着敲（literally，报的是register的地址）。后来我们组live debug了一整周，最后发现是某一个index溢出了

大家对于这种工作模式有什么看法？我个人觉得无论是从deliverable的角度还是知识技能的角度都没什么好处。
这是否是一种正确的合作模式？我完全不觉得这里体现了什么ownership，出了问题没法triage只能一堆人一起live debug是这个组管理的问题还是这种底层infra组确实会遇到的挑战？

我觉得我收获最大的就是看大佬debug，walk the heap找哪个地方corrupt了，分析一段assembly到底在干嘛，要是能给我再解释两句就更妙了。你说的这个可能是由于remote或者是setup的原因效率低了点，但是我觉得对于有心人是提升的良机。你得事后去琢磨为什么要run这个command，为什么要看这个register；debug这种疑难杂症绝对是金刚钻，好好学吧。

我们一般会假装听错，然后大佬就会把conmand敲在聊天里，听写的人直接copy就好

补充内容 (2022-08-06 02:02 +08:00):
对，比如我写错的这个comnand

楼主你把他想成10人+的 pair programming是不是就没有违和感了

在国内，项目现场也基本是这样，share 屏幕，然后我发一个command过去，他执行，我看结果，非常原始，我一个人debug现场问题，有时候现场的朋友对命令不熟悉，就更头秃

有个问题， 为啥指挥的 B （senior / principal) 不能亲自 debug, 而是开会的时候念给 A 听， 难道是 B 没有 debug 的权限 / set up?

potplus 发表于 2022-8-5 03:58
有个问题， 为啥指挥的 B （senior / principal) 不能亲自 debug, 而是开会的时候念给 A 听， 难道是 B 没 ...

因为repro并不是非常trivial的东西，如何repro本身就很困难，可能需要特定的build/setup/操作。

哈哈哈哈 mob programming了解一下

不正常
没有大佬能够信口拈来一个自己从来没用过的指令，说明这个command他经常用，经常用说明经常遇到问题
如果你们debug一周的事件发生超过4次，就意味着N人月的工程资源在debug上，这个足够证明需要花人手去做更好的debug tool

举个例子之前做蓝牙经常遇到不work的场景
通常方式是有地方开启蓝牙debug logging，然后把数据发给蓝牙组
蓝牙出问题无非固件出问题，kernel/sdk出问题，你用的出问题
因为很难复现，包括我们使用方式也很复杂，我写了一个在内存单元测试的框架来看我们用的对不对
有一些跑一万次出现一两次的bug也被我找出来了
当然固件和kernel出问题这个我就修不了了

这种奇怪的bug只能这样啊