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

看板Soft_Job作者 (微酸桔子)時間2年前 (2021/12/27 19:23), 編輯推噓27(29推 2噓 73→)
留言104則, 44人參與, 3年前最新討論串1/4 (看更多)
大家好 小弟剛出社會 在純軟這個行業大約半年 最近code base在做IT的時候打出一個bug 老鳥們沒空所以派我這隻菜鳥去修 當我打開專案開始從模組方向找線索時 老鳥甲路過 看了一眼說 你這樣debug效率有點慢 直接看submit紀錄找戰犯比較快 我試了一下 果然滿快就找到問題點了 根據老鳥甲所說 大概7-80%的bug都可以這樣抓 這裡想詢問各位大大 這種除錯習慣是不是對新手熟悉軟體架構不利 畢竟第一時間都在抓戰犯 而不是去了解目前軟體架構遇到的問題 ---- Sent from BePTT on my OnePlus GM1910 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.247.128.240 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1640604195.A.BC2.html
→
12/27 19:33, 2年前 , 1F
熟悉架構是一回事，除錯是一回事，沒有一定要同一個手段吧
12/27 19:33, 1F
→
12/27 19:34, 2年前 , 2F
記錄不拿來抓錯，記身體健康的?
12/27 19:34, 2F
→
12/27 19:38, 2年前 , 3F
這是兩回事 埋了log但是不熟架構你還是不知道為何出現b
12/27 19:38, 3F
→
12/27 19:38, 2年前 , 4F
ug 但更多的是再熟架構都可能出現奇葩的bug 就是需要lo
12/27 19:38, 4F
→
12/27 19:38, 2年前 , 5F
g去幫忙debug
12/27 19:38, 5F
推
12/27 19:55, 2年前 , 6F
是 submit 記錄還是 commit 記錄呢？
12/27 19:55, 6F
→
12/27 19:56, 2年前 , 7F
submit紀錄 看code diff抓bug
12/27 19:56, 7F
推
12/27 20:01, 2年前 , 8F
我猜貴司沒在code review
12/27 20:01, 8F
→
12/27 20:30, 2年前 , 9F
沒在管控程式碼commit的這樣確實比較快
12/27 20:30, 9F
推
12/27 20:30, 2年前 , 10F
這叫夾版本啦 通常就是週五上code 趕下班 賭一波
12/27 20:30, 10F
→
12/27 20:30, 2年前 , 11F
不驗就直接上啊哈哈哈
12/27 20:30, 11F
→
12/27 20:30, 2年前 , 12F
敝司MTK 抓戰犯也這樣搞啊
12/27 20:30, 12F
推
12/27 20:56, 2年前 , 13F
我以為debug靠log
12/27 20:56, 13F
推
12/27 21:03, 2年前 , 14F
急的話當然從 commit log 與 bug 執行路徑下手
12/27 21:03, 14F
→
12/27 21:04, 2年前 , 15F
要熟悉架構通常開發做吧 除非 bug 不急
12/27 21:04, 15F
推
12/27 22:15, 2年前 , 16F
如果是IT就能抓到的話，有沒有考慮CICD的時候把IT也做了
12/27 22:15, 16F
→
12/27 22:15, 2年前 , 17F
，這樣bug commit進去馬上就能抓到
12/27 22:15, 17F
→
12/27 22:17, 2年前 , 18F
我都這樣找root cause。還有的時候會上issue tracker看
12/27 22:17, 18F
→
12/27 22:17, 2年前 , 19F
看別組有沒有解過類似問題，有的話直接拿來抄，一小時就
12/27 22:17, 19F
→
12/27 22:17, 2年前 , 20F
搞定，然後其餘五天都在打混（？
12/27 22:17, 20F
→
12/27 22:19, 2年前 , 21F
debug mode能用就用，比你單看code更快熟悉架構。
12/27 22:19, 21F
→
12/27 22:22, 2年前 , 22F
我有時候會用Binary search耶 有時候懶得看Code
12/27 22:22, 22F
→
12/27 22:22, 2年前 , 23F
尤其專案真的太大 但能看Code當然會看
12/27 22:22, 23F
→
12/27 22:22, 2年前 , 24F
照理來說 每次的Commit 應該是小區域小區域
12/27 22:22, 24F
推
12/27 22:23, 2年前 , 25F
要熟悉軟體架構的話，可以順便幫忙把class diagram, seq
12/27 22:23, 25F
→
12/27 22:23, 2年前 , 26F
uence diagram畫一畫分享到組內wiki，我會很感謝您
12/27 22:23, 26F
推
12/27 22:30, 2年前 , 27F
夾版本可以用git bisect
12/27 22:30, 27F
推
12/27 22:33, 2年前 , 28F
我也用過 binary search 大法...
12/27 22:33, 28F
→
12/27 22:38, 2年前 , 29F
看到 submit 紀錄還以為是什麼 form...結果是 commit
12/27 22:38, 29F
→
12/27 22:51, 2年前 , 30F
那只是因為他架構比你熟很多才會這樣 而且通常有抓戰
12/27 22:51, 30F
→
12/27 22:53, 2年前 , 31F
犯習慣的公司程式碼幾乎都是屎山 你改他也改 不就看
12/27 22:53, 31F
→
12/27 22:54, 2年前 , 32F
誰哪天被坑到...
12/27 22:54, 32F
→
12/27 22:56, 2年前 , 33F
職場一些小手法很容易看清楚 不過就算老鳥錯他還是活
12/27 22:56, 33F
→
12/27 22:57, 2年前 , 34F
的很滋潤 然後拿crud boy的錢要幫忙處理大事情 做的
12/27 22:57, 34F
→
12/27 22:57, 2年前 , 35F
好也沒獎勵...
12/27 22:57, 35F
→
12/27 23:08, 2年前 , 36F
我也想了一下submit是甚麼 原來只的是交code...
12/27 23:08, 36F
→
12/27 23:22, 2年前 , 37F
推樓樓上
12/27 23:22, 37F
推
12/27 23:49, 2年前 , 38F
git叫做commit 但有些version control叫做submit啦....
12/27 23:49, 38F
→
12/27 23:49, 2年前 , 39F
不用挑語病 原po也不見得講錯
12/27 23:49, 39F
還有 25 則推文
→
12/28 09:19, 2年前 , 65F
後有機會了也是不可能改變了 後面的人會很痛苦
12/28 09:19, 65F
→
12/28 09:20, 2年前 , 66F
要解決的好要了解架構 沒時間當然只能端出一個十分馬
12/28 09:20, 66F
→
12/28 09:21, 2年前 , 67F
乎的成果 出張嘴檢討是很簡單的
12/28 09:21, 67F
→
12/28 09:24, 2年前 , 68F
最後就是繼續堆屎山 反正被檢討的是別人 每個人都想
12/28 09:24, 68F
→
12/28 09:24, 2年前 , 69F
過的好
12/28 09:24, 69F
推
12/28 09:26, 2年前 , 70F
原來大家都用二元搜尋夾版本
12/28 09:26, 70F
推
12/28 09:59, 2年前 , 71F
用commit抓bug跟理解架構不衝突。說先用commit點除錯的無
12/28 09:59, 71F
→
12/28 09:59, 2年前 , 72F
法理解架構，應該是個人就不想去理解。你發現commit的cha
12/28 09:59, 72F
→
12/28 09:59, 2年前 , 73F
nge造成錯誤，仍然會去了解他上下幾層的關係以及邏輯。這
12/28 09:59, 73F
→
12/28 09:59, 2年前 , 74F
兩個方式是相輔相成。
12/28 09:59, 74F
推
12/28 10:10, 2年前 , 75F
form submit +1
12/28 10:10, 75F
→
12/28 10:20, 2年前 , 76F
git bisect
12/28 10:20, 76F
推
12/28 10:29, 2年前 , 77F
一個 commit 引發 bug 不代表錯的是那支 commit 呀 XD
12/28 10:29, 77F
推
12/28 12:06, 2年前 , 78F
12/28 12:06, 78F
→
12/28 12:58, 2年前 , 79F
我以為debug都是用step in step out
12/28 12:58, 79F
噓
12/28 13:45, 2年前 , 80F
可以光靠看diff而不用熟悉架構就能抓出來的bug不就低能錯
12/28 13:45, 80F
→
12/28 13:45, 2年前 , 81F
誤嗎，review時就該看出來的那種
12/28 13:45, 81F
→
12/28 13:48, 2年前 , 82F
但就算是不低能的bug，熟悉系統架構的情況下還是配diff一
12/28 13:48, 82F
→
12/28 13:48, 2年前 , 83F
起看最有效率
12/28 13:48, 83F
推
12/28 13:59, 2年前 , 84F
樓上一個鬼轉耶，那幹嘛要噓人
12/28 13:59, 84F
→
12/28 14:14, 2年前 , 85F
這老鳥甲沒救了
12/28 14:14, 85F
→
12/28 14:16, 2年前 , 86F
原來不是 form submit，推回來
12/28 14:16, 86F
推
12/28 15:54, 2年前 , 87F
你講的兩個domain不同吧 debug跟架構瞭解是兩回事
12/28 15:54, 87F
推
12/28 17:18, 2年前 , 88F
就純噓低能錯誤，推回來
12/28 17:18, 88F
→
12/28 23:16, 2年前 , 89F
db撈出來才造成錯誤的這種方法就沒效了
12/28 23:16, 89F
推
12/29 00:58, 2年前 , 90F
用二元搜尋夾版本是什麼意思？
12/29 00:58, 90F
推
12/29 01:02, 2年前 , 91F
看哪個版本是第一個有bug，看改了什麼鬼
12/29 01:02, 91F
→
12/29 14:13, 2年前 , 92F
長知識
12/29 14:13, 92F
推
12/29 18:55, 2年前 , 93F
改了一點點東西記得commit 然後用git bisect找問題就很快
12/29 18:55, 93F
→
12/29 21:04, 2年前 , 94F
看是哪種bug啊,新改出來的這樣找比較有效率
12/29 21:04, 94F
→
12/30 02:48, 2年前 , 95F
debug用log找吧，找到問題再git history 抓戰犯不是
12/30 02:48, 95F
→
12/30 02:48, 2年前 , 96F
嗎…commit message 能找bug 第一次聽到…
12/30 02:48, 96F
→
12/30 03:19, 2年前 , 97F
更正，是git blame
12/30 03:19, 97F
推
01/01 00:58, 3年前 , 98F
工作要的是效率，事情丟給你要在時間內有結果，解掉是
01/01 00:58, 98F
→
01/01 00:58, 3年前 , 99F
結果，抓到戰犯也是，後者簡單啊，不難理解
01/01 00:58, 99F
推
01/01 04:13, 3年前 , 100F
這有什麼好吵 兩項技能都點滿就好了啊 說實在不要去糾結
01/01 04:13, 100F
→
01/01 04:13, 3年前 , 101F
這些 趕快變強比較實在
01/01 04:13, 101F
推
01/02 08:44, 3年前 , 102F
沒版控就算了,有版控可找BUG了,誰還在管你習慣好不好咧~
01/02 08:44, 102F
→
01/02 08:44, 3年前 , 103F
能找到問題就是好方法啦,不然寫git bisect功能的人不就
01/02 08:44, 103F
→
01/02 08:44, 3年前 , 104F
是軟體界的敗類,教壞大家依賴版控了?
01/02 08:44, 104F
‣ 更多 cytus74 的文章
文章代碼(AID): #1XoQ8Zl2 (Soft_Job)
‣ 更多 cytus74 的文章
文章代碼(AID): #1XoQ8Zl2 (Soft_Job)