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

art112/29 18:32修改壞掉之後一鍵回復到還能動的狀態

hidog12/29 18:33這樣可以順便看一下是哪個修改出問題吧 XD

hidog12/29 18:34回到還能動的狀態也被我歸類是debug行為之一就是

vi00024612/29 18:41這個行為有個指令叫Git Bisect 環境單純的話是還滿方便

vi00024612/29 18:42的 debug工具是多多益善 多學沒壞處

aaa123413612/29 19:00推個 工作上能更有效率，就是好辦法

godsparticle12/29 19:14不是抓戰犯用的嗎 （x)

mrsix12/29 20:20其實就是藉由版本控制來找功能正常到功能失效的分水嶺，可

mrsix12/29 20:20以迅速縮小範圍。

mrsix12/29 20:24找到分水嶺後比對一下程式差異是否和失效現象相關，這樣比

mrsix12/29 20:24較能快速找到分析方向。

mrsix12/29 20:26不過前提是每次上傳程式前都要跑過測試，否則就是賭每個人

mrsix12/29 20:26的紀律了。

mrsix12/29 20:31通常上傳程式前應該都有測試來把關，過不了測試就無法上傳

mrsix12/29 20:31程式，至少要維持基本功能正常。

hidog12/29 20:44通常是merge回去dev前要測試通過,每個commit都要測試完整

hidog12/29 20:44有點難

hidog12/29 20:45另外如果每個commit都是正常能跑，也不需要靠git追一堆comm

hidog12/29 20:45it了

hidog12/29 20:46技術上有困難，測試成本會過高，通常是一個開發結束後才會

hidog12/29 20:46做完整測試

wulouise12/29 21:29merge或pr前測就好吧

jhjhs3350412/29 22:17不能太躁進而且軟體架構設計不良整條拆掉重構都有可能

abc092200112/29 22:33那ID不用太意外啦，他非常討厭 git

viper970912/29 23:29推

SouthRa12/30 01:23highlight一句推文回整篇鞭，你有點可怕...

Dracarys12/30 01:24我以為儘量保持Tip of Tree是綠色的才是正確的？pre co

Dracarys12/30 01:24mmit CI都過才能提交

troylee12/30 01:49bisect 方便多了..

hidog12/30 09:35理想是每個commit都沒問題，實務上看資源夠不夠

hidog12/30 09:36我自己覺得debug方法跟工具沒有優劣，只有適合與否

hidog12/30 09:37個人覺得不應該批評某個方法很蠢之類，只有適合不適合的問

hidog12/30 09:37題

andy83102012/30 10:29還有就是找到不代表要blame啊XD

andy83102012/30 10:29罵了也解決不了問題

andy83102012/30 10:30有時候高耦合真的會 pre commit CI過 但實際出問題

vi00024612/30 11:37他就叫git blame咩 不blame一下是不行的

rednim12/30 13:43推 快速縮小範圍找到問題點之後要修正也比較快

becca94512/30 17:34找到前員工名字blame準沒錯

Belieeve12/30 22:26是說如果分支有合別人的再refactor，還是有可能blame錯

Belieeve12/30 22:26人…

Aidan7922512/31 01:59git bisect真的好用

ybite12/31 18:36測試都有過 跑起來出問題 真的是軟體工程常態

ybite12/31 18:37就算做到95%以上的 Coverage 都很難避免極端狀況

yellowbooky01/02 09:39除非要處理的問題真的很單純，否則再怎麼測都可能有

yellowbooky01/02 09:39漏

joe82073001/02 17:16推，方法沒有好壞，只有當下怎麼做比較合適

XJY1301/08 09:45推