Re: [討論] 靠submit紀錄來除錯是一個不好的習慣嗎

看板Soft_Job作者 (.....)時間4年前 (2021/12/29 18:28), 編輯推噓23(23推 0噓 25→)
留言48則, 22人參與, 最新討論串3/4 (看更多)
※ 引述《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://www.ptt.cc/bbs/Soft_Job/M.1640773733.A.603.html
推
12/29 18:32, 4年前 , 1F
修改壞掉之後一鍵回復到還能動的狀態
12/29 18:32, 1F
→
12/29 18:33, 4年前 , 2F
這樣可以順便看一下是哪個修改出問題吧 XD
12/29 18:33, 2F
→
12/29 18:34, 4年前 , 3F
回到還能動的狀態也被我歸類是debug行為之一就是
12/29 18:34, 3F
推
12/29 18:41, 4年前 , 4F
這個行為有個指令叫Git Bisect 環境單純的話是還滿方便
12/29 18:41, 4F
→
12/29 18:42, 4年前 , 5F
的 debug工具是多多益善 多學沒壞處
12/29 18:42, 5F
推
12/29 19:00, 4年前 , 6F
推個 工作上能更有效率，就是好辦法
12/29 19:00, 6F
推
12/29 19:14, 4年前 , 7F
不是抓戰犯用的嗎 （x)
12/29 19:14, 7F
推
12/29 20:20, 4年前 , 8F
其實就是藉由版本控制來找功能正常到功能失效的分水嶺，可
12/29 20:20, 8F
→
12/29 20:20, 4年前 , 9F
以迅速縮小範圍。
12/29 20:20, 9F
推
12/29 20:24, 4年前 , 10F
找到分水嶺後比對一下程式差異是否和失效現象相關，這樣比
12/29 20:24, 10F
→
12/29 20:24, 4年前 , 11F
較能快速找到分析方向。
12/29 20:24, 11F
推
12/29 20:26, 4年前 , 12F
不過前提是每次上傳程式前都要跑過測試，否則就是賭每個人
12/29 20:26, 12F
→
12/29 20:26, 4年前 , 13F
的紀律了。
12/29 20:26, 13F
推
12/29 20:31, 4年前 , 14F
通常上傳程式前應該都有測試來把關，過不了測試就無法上傳
12/29 20:31, 14F
→
12/29 20:31, 4年前 , 15F
程式，至少要維持基本功能正常。
12/29 20:31, 15F
→
12/29 20:44, 4年前 , 16F
通常是merge回去dev前要測試通過,每個commit都要測試完整
12/29 20:44, 16F
→
12/29 20:44, 4年前 , 17F
有點難
12/29 20:44, 17F
→
12/29 20:45, 4年前 , 18F
另外如果每個commit都是正常能跑，也不需要靠git追一堆comm
12/29 20:45, 18F
→
12/29 20:45, 4年前 , 19F
it了
12/29 20:45, 19F
→
12/29 20:46, 4年前 , 20F
技術上有困難，測試成本會過高，通常是一個開發結束後才會
12/29 20:46, 20F
→
12/29 20:46, 4年前 , 21F
做完整測試
12/29 20:46, 21F
推
12/29 21:29, 4年前 , 22F
merge或pr前測就好吧
12/29 21:29, 22F
推
12/29 22:17, 4年前 , 23F
不能太躁進而且軟體架構設計不良整條拆掉重構都有可能
12/29 22:17, 23F
推
12/29 22:33, 4年前 , 24F
那ID不用太意外啦，他非常討厭 git
12/29 22:33, 24F
推
12/29 23:29, 4年前 , 25F
推
12/29 23:29, 25F
→
12/30 01:23, 4年前 , 26F
highlight一句推文回整篇鞭，你有點可怕...
12/30 01:23, 26F
→
12/30 01:24, 4年前 , 27F
我以為儘量保持Tip of Tree是綠色的才是正確的？pre co
12/30 01:24, 27F
→
12/30 01:24, 4年前 , 28F
mmit CI都過才能提交
12/30 01:24, 28F
推
12/30 01:49, 4年前 , 29F
bisect 方便多了..
12/30 01:49, 29F
→
12/30 09:35, 4年前 , 30F
理想是每個commit都沒問題，實務上看資源夠不夠
12/30 09:35, 30F
→
12/30 09:36, 4年前 , 31F
我自己覺得debug方法跟工具沒有優劣，只有適合與否
12/30 09:36, 31F
→
12/30 09:37, 4年前 , 32F
個人覺得不應該批評某個方法很蠢之類，只有適合不適合的問
12/30 09:37, 32F
→
12/30 09:37, 4年前 , 33F
題
12/30 09:37, 33F
推
12/30 10:29, 4年前 , 34F
還有就是找到不代表要blame啊XD
12/30 10:29, 34F
→
12/30 10:29, 4年前 , 35F
罵了也解決不了問題
12/30 10:29, 35F
→
12/30 10:30, 4年前 , 36F
有時候高耦合真的會 pre commit CI過 但實際出問題
12/30 10:30, 36F
推
12/30 11:37, 4年前 , 37F
他就叫git blame咩 不blame一下是不行的
12/30 11:37, 37F
推
12/30 13:43, 4年前 , 38F
推 快速縮小範圍找到問題點之後要修正也比較快
12/30 13:43, 38F
推
12/30 17:34, 4年前 , 39F
找到前員工名字blame準沒錯
12/30 17:34, 39F
推
12/30 22:26, 4年前 , 40F
是說如果分支有合別人的再refactor，還是有可能blame錯
12/30 22:26, 40F
→
12/30 22:26, 4年前 , 41F
人…
12/30 22:26, 41F
推
12/31 01:59, 4年前 , 42F
git bisect真的好用
12/31 01:59, 42F
推
12/31 18:36, 4年前 , 43F
測試都有過 跑起來出問題 真的是軟體工程常態
12/31 18:36, 43F
→
12/31 18:37, 4年前 , 44F
就算做到95%以上的 Coverage 都很難避免極端狀況
12/31 18:37, 44F
推
01/02 09:39, 5年前 , 45F
除非要處理的問題真的很單純，否則再怎麼測都可能有
01/02 09:39, 45F
→
01/02 09:39, 5年前 , 46F
漏
01/02 09:39, 46F
推
01/02 17:16, 5年前 , 47F
推，方法沒有好壞，只有當下怎麼做比較合適
01/02 17:16, 47F
推
01/08 09:45, , 48F
推
01/08 09:45, 48F
‣ 更多 hidog 的文章
文章代碼(AID): #1Xp3XbO3 (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 3 之 4 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共4篇)
‣ 更多 hidog 的文章
文章代碼(AID): #1Xp3XbO3 (Soft_Job)