[討論] 靠submit紀錄來除錯是一個不好的習慣嗎
大家好 小弟剛出社會 在純軟這個行業大約半年
最近code base在做IT的時候打出一個bug
老鳥們沒空所以派我這隻菜鳥去修
當我打開專案開始從模組方向找線索時
老鳥甲路過 看了一眼說
你這樣debug效率有點慢 直接看submit紀錄找戰犯比較快
我試了一下 果然滿快就找到問題點了
根據老鳥甲所說 大概7-80%的bug都可以這樣抓
這裡想詢問各位大大
這種除錯習慣是不是對新手熟悉軟體架構不利
畢竟第一時間都在抓戰犯 而不是去了解目前軟體架構遇到的問題
----
Sent from BePTT on my OnePlus GM1910
--
熟悉架構是一回事,除錯是一回事,沒有一定要同一個手段吧
記錄不拿來抓錯,記身體健康的?
這是兩回事 埋了log但是不熟架構你還是不知道為何出現b
ug 但更多的是再熟架構都可能出現奇葩的bug 就是需要lo
g去幫忙debug
是 submit 記錄還是 commit 記錄呢?
submit紀錄 看code diff抓bug
我猜貴司沒在code review
沒在管控程式碼commit的這樣確實比較快
這叫夾版本啦 通常就是週五上code 趕下班 賭一波
不驗就直接上啊哈哈哈
敝司MTK 抓戰犯也這樣搞啊
我以為debug靠log
急的話當然從 commit log 與 bug 執行路徑下手
要熟悉架構通常開發做吧 除非 bug 不急
如果是IT就能抓到的話,有沒有考慮CICD的時候把IT也做了
,這樣bug commit進去馬上就能抓到
我都這樣找root cause。還有的時候會上issue tracker看
看別組有沒有解過類似問題,有的話直接拿來抄,一小時就
搞定,然後其餘五天都在打混(?
debug mode能用就用,比你單看code更快熟悉架構。
我有時候會用Binary search耶 有時候懶得看Code
尤其專案真的太大 但能看Code當然會看
照理來說 每次的Commit 應該是小區域小區域
要熟悉軟體架構的話,可以順便幫忙把class diagram, seq
uence diagram畫一畫分享到組內wiki,我會很感謝您
夾版本可以用git bisect
我也用過 binary search 大法...
看到 submit 紀錄還以為是什麼 form...結果是 commit
那只是因為他架構比你熟很多才會這樣 而且通常有抓戰
犯習慣的公司程式碼幾乎都是屎山 你改他也改 不就看
誰哪天被坑到...
職場一些小手法很容易看清楚 不過就算老鳥錯他還是活
的很滋潤 然後拿crud boy的錢要幫忙處理大事情 做的
好也沒獎勵...
我也想了一下submit是甚麼 原來只的是交code...
推樓樓上
git叫做commit 但有些version control叫做submit啦....
不用挑語病 原po也不見得講錯
前公司用perforce印象中就是submit
..原來是commit喔...還以為是form submit
很少這樣查bug 除非是毫無頭緒的 才會看是不是最近改的
通常都是從各種log查吧
/description/
另外提供一個想法,有時候程式較大,主程式跳至子
函數,子函數再跳至孫函數,來來去去的,有可能會
在某一個函數裡面不小心計算錯誤,而造成執行次數
出錯。這種情況可在子函數跟孫函數裡面,各加一個
執行次數計數器,跑完一遍後可以直接查看計數器的
值,就能知道子函數、孫函數各執行了幾次
其實commit 加上票號版本,看功能就能快速對應哪一版bug
搭配changelog管理生成工具
還在對commit, 只能說版控做得還不夠好
老鳥很清楚,bug都是同事生產的,公司一堆廢物啊
不然你debug要花多少時間
了解架構 <= 這個要看你急不急
都火燒屁股了還在了解架構,會被釘得滿頭包
眼前的火滅了有空在自己去研究架構
哪有時間可以給你搞好commit... 一個人又不是另一個
人肚子裡的蛔蟲... 簡單化才是正確的 簡單並不意味著
無法實現複雜功能
通常老鳥當時是bug開始的一員 不管有沒有機會管事 最
熟架構跟debug本身就不衝突
後有機會了也是不可能改變了 後面的人會很痛苦
要解決的好要了解架構 沒時間當然只能端出一個十分馬
乎的成果 出張嘴檢討是很簡單的
最後就是繼續堆屎山 反正被檢討的是別人 每個人都想
過的好
原來大家都用二元搜尋夾版本
用commit抓bug跟理解架構不衝突。說先用commit點除錯的無
法理解架構,應該是個人就不想去理解。你發現commit的cha
nge造成錯誤,仍然會去了解他上下幾層的關係以及邏輯。這
兩個方式是相輔相成。
form submit +1
git bisect
一個 commit 引發 bug 不代表錯的是那支 commit 呀 XD
我以為debug都是用step in step out
可以光靠看diff而不用熟悉架構就能抓出來的bug不就低能錯
誤嗎,review時就該看出來的那種
但就算是不低能的bug,熟悉系統架構的情況下還是配diff一
起看最有效率
樓上一個鬼轉耶,那幹嘛要噓人
這老鳥甲沒救了
原來不是 form submit,推回來
你講的兩個domain不同吧 debug跟架構瞭解是兩回事
就純噓低能錯誤,推回來
db撈出來才造成錯誤的這種方法就沒效了
用二元搜尋夾版本是什麼意思?
看哪個版本是第一個有bug,看改了什麼鬼
長知識
改了一點點東西記得commit 然後用git bisect找問題就很快
看是哪種bug啊,新改出來的這樣找比較有效率
debug用log找吧,找到問題再git history 抓戰犯不是
嗎…commit message 能找bug 第一次聽到…
更正,是git blame
工作要的是效率,事情丟給你要在時間內有結果,解掉是
結果,抓到戰犯也是,後者簡單啊,不難理解
這有什麼好吵 兩項技能都點滿就好了啊 說實在不要去糾結
這些 趕快變強比較實在
沒版控就算了,有版控可找BUG了,誰還在管你習慣好不好咧~
能找到問題就是好方法啦,不然寫git bisect功能的人不就
是軟體界的敗類,教壞大家依賴版控了?
6
我覺得抓bug要看經驗 不同情境有不同的使用方式 像是從git log抓bug,使用git blame指令 是俗稱的抓戰犯 通常用在追踨bug追到一段code23
^^^^^^^^^^^^^^^^^^^^ 有一種狀況是這樣 軟體架構設計不良,高耦合,導致原本要做A功能,卻影響到B功能, 但不好追是哪一行程式造成問題. (開發經驗久的人應該都遇過這種情形) 這種時候我們會需要追是從哪個版本開始壞掉3X
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 程式會造成"軟體架構設計不良,高耦合,導致原本要做A功能,卻影響到B功能," 大部份是git造成的 不知道吧?那這樣算不算"無知"? 想看看git branch來merge去是不是都是一坨屎在那branch來merge去
33
[請益] 讓人頭痛的伸手牌老鳥女口是頁 小弟目前任職軟體公司幾年 公司最近有幾位老鳥同事讓小弟很苦惱 雖然人都很不錯,但說白了就是只適合當朋友。 隨著共事時間推移,小弟翻白眼頻率也漸漸升高。21
Re: [問題] 遇到不友善的老鳥該怎麼辦?問題是你上一篇不是這樣說的 在上一篇裡 你自認你是有經驗的熟手 不是菜鳥11
[討論]部門管理扁平化該如何自處版友大家好,幫一位朋友問的 數月前新進的外商公司部門雖然有主管,但是主管不會監督我們 主管有找一個RD當作leader來抓每次軟體進版的進度要做哪些功能 但是整個流程每個RD都是要自動自發去處理的自己抓時間 沒有人管理只是leader會追進度而已有bug就自主去修9
Re: [請益] 新人時期被放生是正常的嗎?沒惡意,只是說一下個人想法 這篇文章有幾個問題 1. 你應徵什麼職務? 軟體? 硬體? 業務? FAE? 2. 你出社會多久了? 是新鮮人還是老鳥? 3. 主管有要求該學長帶你嗎?