作者:
cytus74 (微酸桔子)
2021-12-27 19:23:13大家好 小弟剛出社會 在純軟這個行業大約半年
最近code base在做IT的時候打出一個bug
老鳥們沒空所以派我這隻菜鳥去修
當我打開專案開始從模組方向找線索時
老鳥甲路過 看了一眼說
你這樣debug效率有點慢 直接看submit紀錄找戰犯比較快
我試了一下 果然滿快就找到問題點了
根據老鳥甲所說 大概7-80%的bug都可以這樣抓
這裡想詢問各位大大
這種除錯習慣是不是對新手熟悉軟體架構不利
畢竟第一時間都在抓戰犯 而不是去了解目前軟體架構遇到的問題
作者:
ssccg (23)
2021-12-27 19:33:00熟悉架構是一回事，除錯是一回事，沒有一定要同一個手段吧記錄不拿來抓錯，記身體健康的?
作者:
bill0205 (善良的小孩沒人愛)
2021-12-27 19:38:00這是兩回事 埋了log但是不熟架構你還是不知道為何出現bug 但更多的是再熟架構都可能出現奇葩的bug 就是需要log去幫忙debug
是 submit 記錄還是 commit 記錄呢？
作者: cytus74 (微酸桔子) 2021-12-27 19:56:00
submit紀錄 看code diff抓bug
作者:
s06i06 (三條魚)
2021-12-27 20:01:00我猜貴司沒在code review
這叫夾版本啦 通常就是週五上code 趕下班 賭一波不驗就直接上啊哈哈哈敝司MTK 抓戰犯也這樣搞啊
作者:
alihue (wanda wanda)
2021-12-27 21:03:00急的話當然從 commit log 與 bug 執行路徑下手要熟悉架構通常開發做吧 除非 bug 不急
作者:
yamakazi (大安吳彥祖)
2021-12-27 22:15:00如果是IT就能抓到的話，有沒有考慮CICD的時候把IT也做了，這樣bug commit進去馬上就能抓到我都這樣找root cause。還有的時候會上issue tracker看看別組有沒有解過類似問題，有的話直接拿來抄，一小時就搞定，然後其餘五天都在打混（？debug mode能用就用，比你單看code更快熟悉架構。
我有時候會用Binary search耶 有時候懶得看Code尤其專案真的太大 但能看Code當然會看照理來說 每次的Commit 應該是小區域小區域
作者:
yamakazi (大安吳彥祖)
2021-12-27 22:23:00要熟悉軟體架構的話，可以順便幫忙把class diagram, sequence diagram畫一畫分享到組內wiki，我會很感謝您
作者:
taikobo (勉強になるなぁ...)
2021-12-27 22:38:00看到 submit 紀錄還以為是什麼 form...結果是 commit
作者: superpandal 2021-12-27 22:51:00
那只是因為他架構比你熟很多才會這樣 而且通常有抓戰犯習慣的公司程式碼幾乎都是屎山 你改他也改 不就看誰哪天被坑到...職場一些小手法很容易看清楚 不過就算老鳥錯他還是活的很滋潤 然後拿crud boy的錢要幫忙處理大事情 做的好也沒獎勵...
作者:
peter98 (新兵)
2021-12-27 23:08:00我也想了一下submit是甚麼 原來只的是交code...
git叫做commit 但有些version control叫做submit啦....不用挑語病 原po也不見得講錯前公司用perforce印象中就是submit
作者:
bill0205 (善良的小孩沒人愛)
2021-12-28 00:11:00..原來是commit喔...還以為是form submit
很少這樣查bug 除非是毫無頭緒的 才會看是不是最近改的通常都是從各種log查吧
另外提供一個想法，有時候程式較大，主程式跳至子函數，子函數再跳至孫函數，來來去去的，有可能會在某一個函數裡面不小心計算錯誤，而造成執行次數出錯。這種情況可在子函數跟孫函數裡面，各加一個執行次數計數器，跑完一遍後可以直接查看計數器的值，就能知道子函數、孫函數各執行了幾次
作者:
acgotaku (otaku)
2021-12-28 01:57:00其實commit 加上票號版本,看功能就能快速對應哪一版bug搭配changelog管理生成工具還在對commit, 只能說版控做得還不夠好
作者: ericthree (如果 她這樣動人) 2021-12-28 08:44:00
不然你debug要花多少時間
作者: hidog (.....) 2021-12-28 09:00:00
了解架構 <= 這個要看你急不急都火燒屁股了還在了解架構,會被釘得滿頭包眼前的火滅了有空在自己去研究架構
作者: superpandal 2021-12-28 09:14:00
哪有時間可以給你搞好commit... 一個人又不是另一個人肚子裡的蛔蟲... 簡單化才是正確的 簡單並不意味著無法實現複雜功能通常老鳥當時是bug開始的一員 不管有沒有機會管事 最
作者:
Lhmstu (lhmstu)
2021-12-28 09:19:00熟架構跟debug本身就不衝突
作者: superpandal 2021-12-28 09:19:00
後有機會了也是不可能改變了 後面的人會很痛苦要解決的好要了解架構 沒時間當然只能端出一個十分馬乎的成果 出張嘴檢討是很簡單的最後就是繼續堆屎山 反正被檢討的是別人 每個人都想過的好
作者:
Csir (張胖胖)
2021-12-28 09:26:00原來大家都用二元搜尋夾版本
作者:
dave123 (宅男就是傳奇)
2021-12-28 09:59:00用commit抓bug跟理解架構不衝突。說先用commit點除錯的無法理解架構，應該是個人就不想去理解。你發現commit的change造成錯誤，仍然會去了解他上下幾層的關係以及邏輯。這兩個方式是相輔相成。
作者: CRPKT (crpkt) 2021-12-28 10:29:00
一個 commit 引發 bug 不代表錯的是那支 commit 呀 XD
作者:
bnd0327 (阿噗噗)
2021-12-28 12:06:00我以為debug都是用step in step out
作者:
SouthRa (南宮雨)
2021-12-28 13:45:00可以光靠看diff而不用熟悉架構就能抓出來的bug不就低能錯誤嗎，review時就該看出來的那種但就算是不低能的bug，熟悉系統架構的情況下還是配diff一起看最有效率
作者:
bnd0327 (阿噗噗)
2021-12-28 13:59:00樓上一個鬼轉耶，那幹嘛要噓人
作者:
knives 2021-12-28 14:14:00這老鳥甲沒救了原來不是 form submit，推回來
你講的兩個domain不同吧 debug跟架構瞭解是兩回事
作者:
SouthRa (南宮雨)
2021-12-28 17:18:00就純噓低能錯誤，推回來
作者:
open2014 (open2014)
2021-12-29 00:58:00用二元搜尋夾版本是什麼意思？
作者: s06yji3 (阿南) 2021-12-29 01:02:00
看哪個版本是第一個有bug，看改了什麼鬼
作者:
kattte (誠實面對自己吧!)
2021-12-29 14:13:00長知識
作者:
kewang (652公車)
2021-12-29 18:55:00改了一點點東西記得commit 然後用git bisect找問題就很快
作者:
luluking (luluking)
2021-12-29 21:04:00看是哪種bug啊,新改出來的這樣找比較有效率
debug用log找吧，找到問題再git history 抓戰犯不是嗎…commit message 能找bug 第一次聽到…更正，是git blame
工作要的是效率，事情丟給你要在時間內有結果，解掉是結果，抓到戰犯也是，後者簡單啊，不難理解
作者:
zased (我只是上PTT查資料)
2020-01-01 04:13:00這有什麼好吵 兩項技能都點滿就好了啊 說實在不要去糾結這些 趕快變強比較實在
沒版控就算了,有版控可找BUG了,誰還在管你習慣好不好咧~能找到問題就是好方法啦,不然寫git bisect功能的人不就是軟體界的敗類,教壞大家依賴版控了?