作者hidog (.....)
看板Soft_Job
标题Re: [讨论] 靠submit纪录来除错是一个不好的习惯吗
时间Wed Dec 29 18:28:51 2021
※ 引述《vi000246 (Vi)》之铭言：
: → kangan987: 推 12/29 11:35
: 推 abraxas: 推 12/29 13:14
: 推 botnet: 推 12/29 13:45
: 推 b87088: 推 12/29 15:56
: 推 sunsamy: 用git抓bug是源於无知,不是本身有多利害,像义和团 12/29 17:25
^^^^^^^^^^^^^^^^^^^^
有一种状况是这样
软体架构设计不良,高耦合,导致原本要做A功能,却影响到B功能,
但不好追是哪一行程式造成问题. (开发经验久的人应该都遇过这种情形)
这种时候我们会需要追是从哪个版本开始坏掉
靠git去回复版本,找出出问题的commit,是一个很有效率的做法.
我认为debug是挑合适作法,在时间要求内解决掉问题
做法本身并没有优劣之分,而是这个做法适不适合目前的处境
没有时间压力的情况下,可以根据bug的源头做架构调整
有时间压力的情况下,靠工具辅助快速找出问题,work around的方式先让东西能动.
用无知来形容用git除错,个人觉得还蛮怪的
是说git这类版控工具的功能之一,就是出问题的时候能查找出是谁,是哪个修改造成bug
拿git来做debug的辅助工具并没有不对,个人感觉 @@
反而我觉得git无法辅助debug的话,那做版控的目的是啥呢....
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.231.58.61 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1640773733.A.603.html
1F：推 art1: 修改坏掉之後一键回复到还能动的状态 12/29 18:32
2F：→ hidog: 这样可以顺便看一下是哪个修改出问题吧 XD 12/29 18:33
3F：→ hidog: 回到还能动的状态也被我归类是debug行为之一就是 12/29 18:34
4F：推 vi000246: 这个行为有个指令叫Git Bisect 环境单纯的话是还满方便 12/29 18:41
5F：→ vi000246: 的 debug工具是多多益善 多学没坏处 12/29 18:42
6F：推 aaa1234136: 推个 工作上能更有效率，就是好办法 12/29 19:00
7F：推 godsparticle: 不是抓战犯用的吗 （x) 12/29 19:14
8F：推 mrsix: 其实就是藉由版本控制来找功能正常到功能失效的分水岭，可 12/29 20:20
9F：→ mrsix: 以迅速缩小范围。 12/29 20:20
10F：推 mrsix: 找到分水岭後比对一下程式差异是否和失效现象相关，这样比 12/29 20:24
11F：→ mrsix: 较能快速找到分析方向。 12/29 20:24
12F：推 mrsix: 不过前提是每次上传程式前都要跑过测试，否则就是赌每个人 12/29 20:26
13F：→ mrsix: 的纪律了。 12/29 20:26
14F：推 mrsix: 通常上传程式前应该都有测试来把关，过不了测试就无法上传 12/29 20:31
15F：→ mrsix: 程式，至少要维持基本功能正常。 12/29 20:31
16F：→ hidog: 通常是merge回去dev前要测试通过,每个commit都要测试完整 12/29 20:44
17F：→ hidog: 有点难 12/29 20:44
18F：→ hidog: 另外如果每个commit都是正常能跑，也不需要靠git追一堆comm 12/29 20:45
19F：→ hidog: it了 12/29 20:45
20F：→ hidog: 技术上有困难，测试成本会过高，通常是一个开发结束後才会 12/29 20:46
21F：→ hidog: 做完整测试 12/29 20:46
22F：推 wulouise: merge或pr前测就好吧 12/29 21:29
23F：推 jhjhs33504: 不能太躁进而且软体架构设计不良整条拆掉重构都有可能 12/29 22:17
24F：推 abc0922001: 那ID不用太意外啦，他非常讨厌 git 12/29 22:33
25F：推 viper9709: 推 12/29 23:29
26F：→ SouthRa: highlight一句推文回整篇鞭，你有点可怕... 12/30 01:23
27F：→ Dracarys: 我以为尽量保持Tip of Tree是绿色的才是正确的？pre co 12/30 01:24
28F：→ Dracarys: mmit CI都过才能提交 12/30 01:24
29F：推 troylee: bisect 方便多了.. 12/30 01:49
30F：→ hidog: 理想是每个commit都没问题，实务上看资源够不够 12/30 09:35
31F：→ hidog: 我自己觉得debug方法跟工具没有优劣，只有适合与否 12/30 09:36
32F：→ hidog: 个人觉得不应该批评某个方法很蠢之类，只有适合不适合的问 12/30 09:37
33F：→ hidog: 题 12/30 09:37
34F：推 andy831020: 还有就是找到不代表要blame啊XD 12/30 10:29
35F：→ andy831020: 骂了也解决不了问题 12/30 10:29
36F：→ andy831020: 有时候高耦合真的会 pre commit CI过 但实际出问题 12/30 10:30
37F：推 vi000246: 他就叫git blame咩 不blame一下是不行的 12/30 11:37
38F：推 rednim: 推 快速缩小范围找到问题点之後要修正也比较快 12/30 13:43
39F：推 becca945: 找到前员工名字blame准没错 12/30 17:34
40F：推 Belieeve: 是说如果分支有合别人的再refactor，还是有可能blame错 12/30 22:26
41F：→ Belieeve: 人… 12/30 22:26
42F：推 Aidan79225: git bisect真的好用 12/31 01:59
43F：推 ybite: 测试都有过 跑起来出问题 真的是软体工程常态 12/31 18:36
44F：→ ybite: 就算做到95%以上的 Coverage 都很难避免极端状况 12/31 18:37
45F：推 yellowbooky: 除非要处理的问题真的很单纯，否则再怎麽测都可能有 01/02 09:39
46F：→ yellowbooky: 漏 01/02 09:39
47F：推 joe820730: 推，方法没有好坏，只有当下怎麽做比较合适 01/02 17:16
48F：推 XJY13: 推 01/08 09:45