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

[hidog (.....)]

※ 引述《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
推 art1: 修改壞掉之後一鍵回復到還能動的狀態
→ hidog: 這樣可以順便看一下是哪個修改出問題吧 XD
→ hidog: 回到還能動的狀態也被我歸類是debug行為之一就是
推 vi000246: 這個行為有個指令叫Git Bisect 環境單純的話是還滿方便
→ vi000246: 的 debug工具是多多益善 多學沒壞處
推 aaa1234136: 推個  工作上能更有效率，就是好辦法
推 godsparticle: 不是抓戰犯用的嗎 （x)
推 mrsix: 其實就是藉由版本控制來找功能正常到功能失效的分水嶺，可
→ mrsix: 以迅速縮小範圍。
推 mrsix: 找到分水嶺後比對一下程式差異是否和失效現象相關，這樣比
→ mrsix: 較能快速找到分析方向。
推 mrsix: 不過前提是每次上傳程式前都要跑過測試，否則就是賭每個人
→ mrsix: 的紀律了。
推 mrsix: 通常上傳程式前應該都有測試來把關，過不了測試就無法上傳
→ mrsix: 程式，至少要維持基本功能正常。
→ hidog: 通常是merge回去dev前要測試通過,每個commit都要測試完整
→ hidog: 有點難
→ hidog: 另外如果每個commit都是正常能跑，也不需要靠git追一堆comm
→ hidog: it了
→ hidog: 技術上有困難，測試成本會過高，通常是一個開發結束後才會
→ hidog: 做完整測試
推 wulouise: merge或pr前測就好吧
推 jhjhs33504: 不能太躁進而且軟體架構設計不良整條拆掉重構都有可能
推 abc0922001: 那ID不用太意外啦，他非常討厭 git
推 viper9709: 推
→ SouthRa: highlight一句推文回整篇鞭，你有點可怕...
→ Dracarys: 我以為儘量保持Tip of Tree是綠色的才是正確的？pre co
→ Dracarys: mmit CI都過才能提交
推 troylee: bisect 方便多了..
→ hidog: 理想是每個commit都沒問題，實務上看資源夠不夠
→ hidog: 我自己覺得debug方法跟工具沒有優劣，只有適合與否
→ hidog: 個人覺得不應該批評某個方法很蠢之類，只有適合不適合的問
→ hidog: 題
推 andy831020: 還有就是找到不代表要blame啊XD
→ andy831020: 罵了也解決不了問題
→ andy831020: 有時候高耦合真的會 pre commit CI過 但實際出問題
推 vi000246: 他就叫git blame咩 不blame一下是不行的
推 rednim: 推 快速縮小範圍找到問題點之後要修正也比較快
推 becca945: 找到前員工名字blame準沒錯
推 Belieeve: 是說如果分支有合別人的再refactor，還是有可能blame錯
→ Belieeve: 人…
推 Aidan79225: git bisect真的好用
推 ybite: 測試都有過 跑起來出問題 真的是軟體工程常態
→ ybite: 就算做到95%以上的 Coverage 都很難避免極端狀況
推 yellowbooky: 除非要處理的問題真的很單純，否則再怎麼測都可能有
→ yellowbooky: 漏
推 joe820730: 推，方法沒有好壞，只有當下怎麼做比較合適
推 XJY13: 推