[討論] 重構之前要寫測試 不然不要重構

看板Soft_Job作者 (貓丸)時間3年前 (2020/07/02 02:48), 3年前編輯推噓26(35推 9噓 90→)
留言134則, 61人參與, 3年前最新討論串1/3 (看更多)
想想這應該算是一種迷思吧 理論上是這樣沒錯 但事實上之前都沒寫測試了 你怎麼證明他之前是對的呢? 所以我大多都直接給他改下去 反正重構後東西也比較清楚 即使有錯 也比起蝦雞巴狗爛毛程式碼好除錯 之前前輩都說會動的程式碼不要去碰 然後就一球在那邊 我說要改 他就說 [啊你有寫測試嗎?] 開發時程又不允許 就一球在那邊越來越痛苦 會動的爛程式碼越來越多 不知道大家怎麼看 ----- Sent from JPTT on my Sony F5321. -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.15.130.230 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1593629319.A.05A.html ※ 編輯: Ghamu (101.15.130.230 臺灣), 07/02/2020 02:52:31
推
07/02 04:01, 3年前 , 1F
如果是老程式碼可以把手測流程自動化成functional test
07/02 04:01, 1F
→
07/02 04:01, 3年前 , 2F
不用執著於一定要寫unit test
07/02 04:01, 2F
→
07/02 04:02, 3年前 , 3F
如此一來不須要100% coverage也能安心重構
07/02 04:02, 3F
推
07/02 07:25, 3年前 , 4F
證明他是對的這件事因為在正式環境運行一段時間了沒
07/02 07:25, 4F
→
07/02 07:25, 3年前 , 5F
有使用者反應問題，基本上就是證明他沒錯
07/02 07:25, 5F
噓
07/02 07:26, 3年前 , 6F
你怎麼證明他之前寫的是對的?是不是連需求都不清楚
07/02 07:26, 6F
推
07/02 07:29, 3年前 , 7F
不是證明是對的。是要證明改前後的輸出是一樣的。
07/02 07:29, 7F
→
07/02 07:30, 3年前 , 8F
很多情況是函式Ａ寫錯除二 Ｂ只好跟著錯乘二 補回來
07/02 07:30, 8F
→
07/02 07:31, 3年前 , 9F
這時候只重構Ａ或是只重構Ｂ都不能把錯誤"改正"
07/02 07:31, 9F
→
07/02 07:31, 3年前 , 10F
因為無法確定是不是只有Ｂ會吃到Ａ的結果。
07/02 07:31, 10F
→
07/02 07:32, 3年前 , 11F
全新的需求就可以跟使用者來回確認。重構跟開發全新
07/02 07:32, 11F
→
07/02 07:32, 3年前 , 12F
需求是兩件事，你沒辦法在跟使用者去確認，所以你只
07/02 07:32, 12F
→
07/02 07:32, 3年前 , 13F
能自己確認
07/02 07:32, 13F
噓
07/02 07:53, 3年前 , 14F
好好寫不行嗎
07/02 07:53, 14F
推
07/02 08:04, 3年前 , 15F
好險你沒改到出包 哪天出包你就知道為啥前輩都放著
07/02 08:04, 15F
→
07/02 08:04, 3年前 , 16F
不管了 嘻嘻
07/02 08:04, 16F
推
07/02 08:11, 3年前 , 17F
公司現在就能賺錢，為什麼要另外花成本重構？
07/02 08:11, 17F
→
07/02 08:11, 3年前 , 18F
測試只是為了得出相同結果的手段，你的目的是想重構
07/02 08:11, 18F
→
07/02 08:11, 3年前 , 19F
而不是減少測試。
07/02 08:11, 19F
→
07/02 08:11, 3年前 , 20F
你要提出重構的效益說服pm、老闆，而不是前輩，老闆
07/02 08:11, 20F
→
07/02 08:11, 3年前 , 21F
覺得重構好就會做了。
07/02 08:11, 21F
推
07/02 08:12, 3年前 , 22F
覺得樓上說的非常中肯，各種教條要配合想要的結果跟手段
07/02 08:12, 22F
→
07/02 08:13, 3年前 , 23F
盲從跟隨便說教條是迷思，而不看自己的情況、背後的理由
07/02 08:13, 23F
→
07/02 08:13, 3年前 , 24F
都不太好
07/02 08:13, 24F
推
07/02 08:18, 3年前 , 25F
理性是要有測試再重構，但還是要考慮實務問題
07/02 08:18, 25F
→
07/02 08:19, 3年前 , 26F
理想 打錯字
07/02 08:19, 26F
→
07/02 08:28, 3年前 , 27F
去找RD lead決鬥阿 pm懂個小喔
07/02 08:28, 27F
→
07/02 08:50, 3年前 , 28F
你要拿你的績效賭誰管得著
07/02 08:50, 28F
推
07/02 09:12, 3年前 , 29F
抱著離職的決心就可以唷
07/02 09:12, 29F
推
07/02 09:14, 3年前 , 30F
估開發時間就是要把測試考慮進去啊
07/02 09:14, 30F
→
07/02 09:31, 3年前 , 31F
你如果在開發團隊中夠力,可以去做,不然最好先找下一家
07/02 09:31, 31F
→
07/02 09:32, 3年前 , 32F
有沒有想過你改了人家東西,原負責人拒絕維護誰會死
07/02 09:32, 32F
→
07/02 09:32, 3年前 , 33F
你可以接下他的工作嗎?
07/02 09:32, 33F
→
07/02 09:34, 3年前 , 34F
這行亂動不屬於自己的東西來配合自己想法,是大忌!
07/02 09:34, 34F
→
07/02 09:38, 3年前 , 35F
團隊若實行code review和ticket system 哪有不能改的程式
07/02 09:38, 35F
→
07/02 09:39, 3年前 , 36F
我待過工廠IT也待過agile開發 製造業IT很符合樓上的說法
07/02 09:39, 36F
噓
07/02 10:34, 3年前 , 37F
他之前寫的程式還有在幫公司賺錢就是對的
07/02 10:34, 37F
推
07/02 10:36, 3年前 , 38F
這是在釣魚？
07/02 10:36, 38F
→
07/02 11:10, 3年前 , 39F
程式對不對跟spec上怎麼定義有關，怎麼會跟有沒有測試
07/02 11:10, 39F
還有 55 則推文
→
07/02 21:11, 3年前 , 95F
或是趁著需求變更順便做效果也不錯
07/02 21:11, 95F
→
07/02 22:50, 3年前 , 96F
小範圍重構免強睜一隻眼閉一隻眼說肉眼可判斷不會出錯
07/02 22:50, 96F
→
07/02 22:51, 3年前 , 97F
大範圍重構還不寫測試是想?
07/02 22:51, 97F
推
07/02 22:54, 3年前 , 98F
可憐哪 還在重構
07/02 22:54, 98F
→
07/02 23:08, 3年前 , 99F
一池豬屎，好不容易經過時間的累積，終於表面乾掉不會臭，就
07/02 23:08, 99F
→
07/02 23:08, 3年前 , 100F
沒必要去攪動它了！
07/02 23:08, 100F
→
07/02 23:49, 3年前 , 101F
目前手上的程式連文件spec 都沒有 所以我隨便改沒差
07/02 23:49, 101F
推
07/03 00:24, 3年前 , 102F
上班沒空寫測試 下班寫啊 就這麼簡單
07/03 00:24, 102F
推
07/03 00:32, 3年前 , 103F
你終究要作測試驗證，何不一開始就寫測試
07/03 00:32, 103F
→
07/03 08:15, 3年前 , 104F
大家講的差不多了，測試就是幫助確認品質，而已經上線過
07/03 08:15, 104F
→
07/03 08:15, 3年前 , 105F
的系統某種程度就是就過驗證的；所以不要偏離原本的行為
07/03 08:15, 105F
→
07/03 08:15, 3年前 , 106F
是有價值的，就看這個價值對你來說有多少（系統多少人使
07/03 08:15, 106F
→
07/03 08:15, 3年前 , 107F
用、是不是完全不能出錯的系統）
07/03 08:15, 107F
推
07/03 10:27, 3年前 , 108F
直接改下去，萬一發現改不好不是進退兩難?
07/03 10:27, 108F
噓
07/03 15:06, 3年前 , 109F
長官沒說改,就別動嘿
07/03 15:06, 109F
→
07/03 20:51, 3年前 , 110F
就算不說測試，你怎麼證明你寫的會比原來的好？你覺得你
07/03 20:51, 110F
→
07/03 20:51, 3年前 , 111F
寫的比較好debug那只是因為是自己寫的啊，你走人後別人也
07/03 20:51, 111F
→
07/03 20:51, 3年前 , 112F
會這麼認為嗎？顆顆
07/03 20:51, 112F
→
07/03 21:36, 3年前 , 113F
會啊，之後還請我做consultant
07/03 21:36, 113F
推
07/04 10:47, 3年前 , 114F
比較殘酷的是....說沒時間寫測試的，實際給了時間還是寫不
07/04 10:47, 114F
→
07/04 10:47, 3年前 , 115F
出來QQ
07/04 10:47, 115F
推
07/04 11:19, 3年前 , 116F
還沒有真的user勇敢改不要怕 有真的user就問問看pm
07/04 11:19, 116F
噓
07/04 11:42, 3年前 , 117F
妳問題比較大 開發時程不夠兩件事 1.能力不足 2.看不清
07/04 11:42, 117F
→
07/04 11:42, 3年前 , 118F
等級在哪邊 還想要重構
07/04 11:42, 118F
推
07/04 12:03, 3年前 , 119F
嘻嘻 你確定你改完會比較好維護? 一堆越構越爛邏輯越複
07/04 12:03, 119F
→
07/04 12:03, 3年前 , 120F
雜的例子
07/04 12:03, 120F
推
07/04 16:23, 3年前 , 121F
你的實力沒被認同才會被這樣說,只能靠你自己証明
07/04 16:23, 121F
→
07/04 16:24, 3年前 , 122F
如果你很強,怎麼做都是可行的
07/04 16:24, 122F
→
07/04 17:22, 3年前 , 123F
要了解架構才能寫出好的，有意義的測項吧
07/04 17:22, 123F
→
07/04 17:23, 3年前 , 124F
沒有了解，你能確定你的測法是正確的嗎
07/04 17:23, 124F
推
07/05 12:18, 3年前 , 125F
因為你只是改成你認為正確的，事實上現在運作沒出大問題
07/05 12:18, 125F
→
07/05 12:20, 3年前 , 126F
也許你寫出來的只是對你來說 你比較好debug
07/05 12:20, 126F
→
07/05 12:20, 3年前 , 127F
因為是你寫的，所以你會知道問題在哪，但對別人來說不是
07/05 12:20, 127F
→
07/06 01:27, 3年前 , 128F
其實應該說清楚一點 本來程式一大球 好幾行 分崩離析 拆成
07/06 01:27, 128F
→
07/06 01:27, 3年前 , 129F
小分小分 即使有錯也比一整包天書好解決吧
07/06 01:27, 129F
推
07/06 07:25, 3年前 , 130F
啊人家就會動沒出錯 哪會比你沒寫測試重構出錯差?
07/06 07:25, 130F
推
07/06 07:29, 3年前 , 131F
爛code至少用能動說服大家它能用了 你連測試都不想寫
07/06 07:29, 131F
→
07/06 07:29, 3年前 , 132F
要怎麼說服別人重構會比較好?
07/06 07:29, 132F
→
07/06 17:20, 3年前 , 133F
原PO似乎弄錯測試程式的目的了? 測試是為了確保行為一致
07/06 17:20, 133F
→
07/06 17:21, 3年前 , 134F
輸出正確與否 不是測試程式應該著力的點
07/06 17:21, 134F
‣ 更多 Ghamu 的文章
文章代碼(AID): #1U_Dg71Q (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 3 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共3篇)
‣ 更多 Ghamu 的文章
文章代碼(AID): #1U_Dg71Q (Soft_Job)