※ 引述《Ghamu (貓丸)》之銘言：
: 但事實上之前都沒寫測試了
: 你怎麼證明他之前是對的呢?
這就是TAD, 一般做法是假設以前人做的是對的
拿以前的output當測資 避免以後的output跟預期結果不同
技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check
這應該不在討論範圍內, 也有客觀標準
行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳
要嘛就是寫的人弄拙成巧 剛好做對
所以在沒有規格跟明確定義的狀況下寫測試 只是寫的人自己覺得對而已
test code也是code 也一樣要維護 也一樣有可能會寫錯
: 所以我大多都直接給他改下去
: 反正重構後東西也比較清楚
: 即使有錯 也比起蝦雞巴狗爛毛程式碼好除錯
每個人都覺得對方code爛 現在我都用: 我就爛 的心態來寫
: 之前前輩都說會動的程式碼不要去碰
: 然後就一球在那邊
: 我說要改 他就說
: [啊你有寫測試嗎?]
: 開發時程又不允許
你沒聽出話中話 人家前輩是好心人
大家都寫程式 又不是你最聰明 所有人都知道時程不允許
你改了code 出現一堆bug 鍋在你頭上
對方一方面也知道那是爛code不想明講 搞不好寫爛code的人還在公司
一方面也知道重構沒有多少績效 做不好還惹得一身臭 期望值低到爆表
人家處處為你著想 你何苦先入為主
要是我是你同事 一定默默地讓你重構
: 就一球在那邊越來越痛苦
: 會動的爛程式碼越來越多
: 不知道大家怎麼看
ptt都是菁英群
基本上大家寫code都是clean code 還有落實unit test
要不是待在根本沒有legacy code的新創公司
要嘛就是會把數以萬計的legacy code補完unit test的楷模員工
你要是在的公司根本沒有在寫test
說明你公司太爛 八成沒一個同事是鄉民
建議你換好一點的公司 再上ptt跟大家討論 比較有共同基準