作者cytus74 (微酸桔子)
看板Soft_Job
标题[讨论] 靠submit纪录来除错是一个不好的习惯吗
时间Mon Dec 27 19:23:13 2021
大家好 小弟刚出社会 在纯软这个行业大约半年
最近code base在做IT的时候打出一个bug
老鸟们没空所以派我这只菜鸟去修
当我打开专案开始从模组方向找线索时
老鸟甲路过 看了一眼说
你这样debug效率有点慢 直接看submit纪录找战犯比较快
我试了一下 果然满快就找到问题点了
根据老鸟甲所说 大概7-80%的bug都可以这样抓
这里想询问各位大大
这种除错习惯是不是对新手熟悉软体架构不利
毕竟第一时间都在抓战犯 而不是去了解目前软体架构遇到的问题
----
Sent from
BePTT on my OnePlus GM1910
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 27.247.128.240 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1640604195.A.BC2.html
1F：→ ssccg: 熟悉架构是一回事，除错是一回事，没有一定要同一个手段吧 12/27 19:33
2F：→ ssccg: 记录不拿来抓错，记身体健康的? 12/27 19:34
3F：→ bill0205: 这是两回事 埋了log但是不熟架构你还是不知道为何出现b 12/27 19:38
4F：→ bill0205: ug 但更多的是再熟架构都可能出现奇葩的bug 就是需要lo 12/27 19:38
5F：→ bill0205: g去帮忙debug 12/27 19:38
6F：推 alan23273850: 是 submit 记录还是 commit 记录呢？ 12/27 19:55
7F：→ cytus74: submit纪录 看code diff抓bug 12/27 19:56
8F：推 s06i06: 我猜贵司没在code review 12/27 20:01
9F：→ nh60211as: 没在管控程式码commit的这样确实比较快 12/27 20:30
10F：推 Onnnnnnnnnnn: 这叫夹版本啦 通常就是周五上code 赶下班 赌一波 12/27 20:30
11F：→ Onnnnnnnnnnn: 不验就直接上啊哈哈哈 12/27 20:30
12F：→ Onnnnnnnnnnn: 敝司MTK 抓战犯也这样搞啊 12/27 20:30
13F：推 samioplg: 我以为debug靠log 12/27 20:56
14F：推 alihue: 急的话当然从 commit log 与 bug 执行路径下手 12/27 21:03
15F：→ alihue: 要熟悉架构通常开发做吧 除非 bug 不急 12/27 21:04
16F：推 yamakazi: 如果是IT就能抓到的话，有没有考虑CICD的时候把IT也做了 12/27 22:15
17F：→ yamakazi: ，这样bug commit进去马上就能抓到 12/27 22:15
18F：→ yamakazi: 我都这样找root cause。还有的时候会上issue tracker看 12/27 22:17
19F：→ yamakazi: 看别组有没有解过类似问题，有的话直接拿来抄，一小时就 12/27 22:17
20F：→ yamakazi: 搞定，然後其余五天都在打混（？ 12/27 22:17
21F：→ yamakazi: debug mode能用就用，比你单看code更快熟悉架构。 12/27 22:19
22F：→ charliejack: 我有时候会用Binary search耶 有时候懒得看Code 12/27 22:22
23F：→ charliejack: 尤其专案真的太大 但能看Code当然会看 12/27 22:22
24F：→ charliejack: 照理来说 每次的Commit 应该是小区域小区域 12/27 22:22
25F：推 yamakazi: 要熟悉软体架构的话，可以顺便帮忙把class diagram, seq 12/27 22:23
26F：→ yamakazi: uence diagram画一画分享到组内wiki，我会很感谢您 12/27 22:23
27F：推 yamakazi: 夹版本可以用git bisect 12/27 22:30
28F：推 alan23273850: 我也用过 binary search 大法... 12/27 22:33
29F：→ taikobo: 看到 submit 纪录还以为是什麽 form...结果是 commit 12/27 22:38
30F：→ superpandal: 那只是因为他架构比你熟很多才会这样 而且通常有抓战 12/27 22:51
31F：→ superpandal: 犯习惯的公司程式码几乎都是屎山 你改他也改 不就看 12/27 22:53
32F：→ superpandal: 谁哪天被坑到... 12/27 22:54
33F：→ superpandal: 职场一些小手法很容易看清楚 不过就算老鸟错他还是活 12/27 22:56
34F：→ superpandal: 的很滋润 然後拿crud boy的钱要帮忙处理大事情 做的 12/27 22:57
35F：→ superpandal: 好也没奖励... 12/27 22:57
36F：→ peter98: 我也想了一下submit是甚麽 原来只的是交code... 12/27 23:08
37F：→ viper9709: 推楼楼上 12/27 23:22
38F：推 kurtsgm: git叫做commit 但有些version control叫做submit啦.... 12/27 23:49
39F：→ kurtsgm: 不用挑语病 原po也不见得讲错 12/27 23:49
40F：→ kurtsgm: 前公司用perforce印象中就是submit 12/27 23:50
41F：推 bill0205: ..原来是commit喔...还以为是form submit 12/28 00:11
42F：→ vi000246: 很少这样查bug 除非是毫无头绪的 才会看是不是最近改的 12/28 00:33
43F：→ vi000246: 通常都是从各种log查吧 12/28 00:33
45F：→ Gaogaigar: /description/ 12/28 01:06
46F：推 JasonChou007: 另外提供一个想法，有时候程式较大，主程式跳至子 12/28 01:38
47F：→ JasonChou007: 函数，子函数再跳至孙函数，来来去去的，有可能会 12/28 01:38
48F：→ JasonChou007: 在某一个函数里面不小心计算错误，而造成执行次数 12/28 01:38
49F：→ JasonChou007: 出错。这种情况可在子函数跟孙函数里面，各加一个 12/28 01:38
50F：→ JasonChou007: 执行次数计数器，跑完一遍後可以直接查看计数器的 12/28 01:38
51F：→ JasonChou007: 值，就能知道子函数、孙函数各执行了几次 12/28 01:38
52F：→ acgotaku: 其实commit 加上票号版本,看功能就能快速对应哪一版bug 12/28 01:57
53F：→ acgotaku: 搭配changelog管理生成工具 12/28 01:58
54F：→ acgotaku: 还在对commit, 只能说版控做得还不够好 12/28 01:58
55F：嘘 darkMood: 老鸟很清楚，bug都是同事生产的，公司一堆废物啊 12/28 02:28
56F：→ ericthree: 不然你debug要花多少时间 12/28 08:44
57F：推 hidog: 了解架构 <= 这个要看你急不急 12/28 09:00
58F：→ hidog: 都火烧屁股了还在了解架构,会被钉得满头包 12/28 09:01
59F：→ hidog: 眼前的火灭了有空在自己去研究架构 12/28 09:01
60F：→ superpandal: 哪有时间可以给你搞好commit... 一个人又不是另一个 12/28 09:14
61F：→ superpandal: 人肚子里的蛔虫... 简单化才是正确的 简单并不意味着 12/28 09:15
62F：→ superpandal: 无法实现复杂功能 12/28 09:16
63F：→ superpandal: 通常老鸟当时是bug开始的一员 不管有没有机会管事 最 12/28 09:18
64F：推 Lhmstu: 熟架构跟debug本身就不冲突 12/28 09:19
65F：→ superpandal: 後有机会了也是不可能改变了 後面的人会很痛苦 12/28 09:19
66F：→ superpandal: 要解决的好要了解架构 没时间当然只能端出一个十分马 12/28 09:20
67F：→ superpandal: 乎的成果 出张嘴检讨是很简单的 12/28 09:21
68F：→ superpandal: 最後就是继续堆屎山 反正被检讨的是别人 每个人都想 12/28 09:24
69F：→ superpandal: 过的好 12/28 09:24
70F：推 Csir: 原来大家都用二元搜寻夹版本 12/28 09:26
71F：推 dave123: 用commit抓bug跟理解架构不冲突。说先用commit点除错的无 12/28 09:59
72F：→ dave123: 法理解架构，应该是个人就不想去理解。你发现commit的cha 12/28 09:59
73F：→ dave123: nge造成错误，仍然会去了解他上下几层的关系以及逻辑。这 12/28 09:59
74F：→ dave123: 两个方式是相辅相成。 12/28 09:59
75F：推 abc0922001: form submit +1 12/28 10:10
76F：→ ScottOAO: git bisect 12/28 10:20
77F：推 CRPKT: 一个 commit 引发 bug 不代表错的是那支 commit 呀 XD 12/28 10:29
79F：→ eva19452002: 我以为debug都是用step in step out 12/28 12:58
80F：嘘 SouthRa: 可以光靠看diff而不用熟悉架构就能抓出来的bug不就低能错 12/28 13:45
81F：→ SouthRa: 误吗，review时就该看出来的那种 12/28 13:45
82F：→ SouthRa: 但就算是不低能的bug，熟悉系统架构的情况下还是配diff一 12/28 13:48
83F：→ SouthRa: 起看最有效率 12/28 13:48
84F：推 bnd0327: 楼上一个鬼转耶，那干嘛要嘘人 12/28 13:59
85F：→ knives: 这老鸟甲没救了 12/28 14:14
86F：→ knives: 原来不是 form submit，推回来 12/28 14:16
87F：推 andy831020: 你讲的两个domain不同吧 debug跟架构了解是两回事 12/28 15:54
88F：推 SouthRa: 就纯嘘低能错误，推回来 12/28 17:18
89F：→ lazarus1121: db捞出来才造成错误的这种方法就没效了 12/28 23:16
90F：推 open2014: 用二元搜寻夹版本是什麽意思？ 12/29 00:58
91F：推 s06yji3: 看哪个版本是第一个有bug，看改了什麽鬼 12/29 01:02
92F：→ kattte: 长知识 12/29 14:13
93F：推 kewang: 改了一点点东西记得commit 然後用git bisect找问题就很快 12/29 18:55
94F：→ luluking: 看是哪种bug啊,新改出来的这样找比较有效率 12/29 21:04
95F：→ crazylunar: debug用log找吧，找到问题再git history 抓战犯不是 12/30 02:48
96F：→ crazylunar: 吗…commit message 能找bug 第一次听到… 12/30 02:48
97F：→ crazylunar: 更正，是git blame 12/30 03:19
98F：推 physicsdk: 工作要的是效率，事情丢给你要在时间内有结果，解掉是 01/01 00:58
99F：→ physicsdk: 结果，抓到战犯也是，後者简单啊，不难理解 01/01 00:58
100F：推 zased: 这有什麽好吵 两项技能都点满就好了啊 说实在不要去纠结 01/01 04:13
101F：→ zased: 这些 赶快变强比较实在 01/01 04:13
102F：推 mithuang: 没版控就算了,有版控可找BUG了,谁还在管你习惯好不好咧~ 01/02 08:44
103F：→ mithuang: 能找到问题就是好方法啦,不然写git bisect功能的人不就 01/02 08:44
104F：→ mithuang: 是软体界的败类,教坏大家依赖版控了? 01/02 08:44