作者Ghamu (貓丸)
看板Soft_Job
標題[討論] 重構之前要寫測試 不然不要重構
時間Thu Jul 2 02:48:37 2020
想想這應該算是一種迷思吧
理論上是這樣沒錯
但事實上之前都沒寫測試了
你怎麼證明他之前是對的呢?
所以我大多都直接給他改下去
反正重構後東西也比較清楚
即使有錯 也比起蝦雞巴狗爛毛程式碼好除錯
之前前輩都說會動的程式碼不要去碰
然後就一球在那邊
我說要改 他就說
[啊你有寫測試嗎?]
開發時程又不允許
就一球在那邊越來越痛苦
會動的爛程式碼越來越多
不知道大家怎麼看
-----
Sent from JPTT on my Sony F5321.
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.15.130.230 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1593629319.A.05A.html
※ 編輯: Ghamu (101.15.130.230 臺灣), 07/02/2020 02:52:31
1F：推 ousapas: 如果是老程式碼可以把手測流程自動化成functional test 07/02 04:01
2F：→ ousapas: 不用執著於一定要寫unit test 07/02 04:01
3F：→ ousapas: 如此一來不須要100% coverage也能安心重構 07/02 04:02
4F：推 keyboard56: 證明他是對的這件事因為在正式環境運行一段時間了沒 07/02 07:25
5F：→ keyboard56: 有使用者反應問題，基本上就是證明他沒錯 07/02 07:25
6F：噓 chchang0820: 你怎麼證明他之前寫的是對的?是不是連需求都不清楚 07/02 07:26
7F：推 NDark: 不是證明是對的。是要證明改前後的輸出是一樣的。 07/02 07:29
8F：→ NDark: 很多情況是函式Ａ寫錯除二 Ｂ只好跟著錯乘二 補回來 07/02 07:30
9F：→ NDark: 這時候只重構Ａ或是只重構Ｂ都不能把錯誤"改正" 07/02 07:31
10F：→ NDark: 因為無法確定是不是只有Ｂ會吃到Ａ的結果。 07/02 07:31
11F：→ keyboard56: 全新的需求就可以跟使用者來回確認。重構跟開發全新 07/02 07:32
12F：→ keyboard56: 需求是兩件事，你沒辦法在跟使用者去確認，所以你只 07/02 07:32
13F：→ keyboard56: 能自己確認 07/02 07:32
14F：噓 alihue: 好好寫不行嗎 07/02 07:53
15F：推 GinginDenSha: 好險你沒改到出包 哪天出包你就知道為啥前輩都放著 07/02 08:04
16F：→ GinginDenSha: 不管了 嘻嘻 07/02 08:04
17F：推 shingatter: 公司現在就能賺錢，為什麼要另外花成本重構？ 07/02 08:11
18F：→ shingatter: 測試只是為了得出相同結果的手段，你的目的是想重構 07/02 08:11
19F：→ shingatter: 而不是減少測試。 07/02 08:11
20F：→ shingatter: 你要提出重構的效益說服pm、老闆，而不是前輩，老闆 07/02 08:11
21F：→ shingatter: 覺得重構好就會做了。 07/02 08:11
22F：推 yyhsiu: 覺得樓上說的非常中肯，各種教條要配合想要的結果跟手段 07/02 08:12
23F：→ yyhsiu: 盲從跟隨便說教條是迷思，而不看自己的情況、背後的理由 07/02 08:13
24F：→ yyhsiu: 都不太好 07/02 08:13
25F：推 hidog: 理性是要有測試再重構，但還是要考慮實務問題 07/02 08:18
26F：→ hidog: 理想 打錯字 07/02 08:19
27F：→ x000032001: 去找RD lead決鬥阿 pm懂個小喔 07/02 08:28
28F：→ Murasaki0110: 你要拿你的績效賭誰管得著 07/02 08:50
29F：推 vi000246: 抱著離職的決心就可以唷 07/02 09:12
30F：推 Csongs: 估開發時間就是要把測試考慮進去啊 07/02 09:14
31F：→ allenxxx: 你如果在開發團隊中夠力,可以去做,不然最好先找下一家 07/02 09:31
32F：→ allenxxx: 有沒有想過你改了人家東西,原負責人拒絕維護誰會死 07/02 09:32
33F：→ allenxxx: 你可以接下他的工作嗎? 07/02 09:32
34F：→ allenxxx: 這行亂動不屬於自己的東西來配合自己想法,是大忌! 07/02 09:34
35F：→ umum29: 團隊若實行code review和ticket system 哪有不能改的程式 07/02 09:38
36F：→ umum29: 我待過工廠IT也待過agile開發 製造業IT很符合樓上的說法 07/02 09:39
37F：噓 DCTmaybe: 他之前寫的程式還有在幫公司賺錢就是對的 07/02 10:34
38F：推 a926: 這是在釣魚？ 07/02 10:36
39F：→ Masakiad: 程式對不對跟spec上怎麼定義有關，怎麼會跟有沒有測試 07/02 11:10
40F：→ Masakiad: 有關？一開始的核心概念沒搞懂你才會問這樣的問題 07/02 11:10
41F：推 strike5566: 說的很對，反正績效算你的，技術債上門時大概也升官 07/02 12:09
42F：→ strike5566: 跳槽了 07/02 12:09
43F：推 brucetu: 反正改壞了出包你負全責不要推託說原本的code很爛 07/02 12:39
44F：→ brucetu: 那你愛怎麼改都可以 07/02 12:39
45F：→ leo5916267: 寫測試也要懂以前的邏輯脈絡，但會重構就是以前的程 07/02 12:50
46F：→ leo5916267: 式混雜一起 07/02 12:50
47F：→ leo5916267: 到最後大家都不想補技術債，只想亂寫，然後bugfix在 07/02 12:51
48F：→ leo5916267: 丟給菜鳥亂補 07/02 12:51
49F：推 Csongs: 真的很少接到舒服的code 07/02 12:52
50F：推 sniper2824: 你考機想吃餅我沒意見啊 07/02 12:59
51F：推 king22649: 把這時間省下來 刷leetcode、練英文比較實在 07/02 13:08
52F：→ deray: 工啥小啦幹 07/02 13:36
53F：推 Masakiad: 推文看下來覺得這些系統真的很堪憂阿 07/02 13:56
54F：→ cphe: 這老議題了... 07/02 14:00
55F：→ NTULioner: 工作不要出包最重要 07/02 14:20
56F：→ NTULioner: 改好 上面不覺得有功 改爛馬上變戰犯 07/02 14:21
57F：噓 annheilong: 怎麼證明之前的對不對 不就是寫測試去驗證嗎... 07/02 14:23
58F：→ shooter555: 就是遇過有人說要重構 然後也重構了 結果一堆bug又不 07/02 14:33
59F：→ shooter555: 修 然後只好等下一個人來重構loop? 07/02 14:33
60F：→ Masakiad: 樓上，所以才要先寫測試後才重構，然後重構目標跟debug 07/02 15:01
61F：→ Masakiad: 完全不同，怎麼回有bug結果又重構這種操作？ 07/02 15:01
62F：噓 as23041248: 時程都不允許還重構0.0 07/02 15:04
63F：噓 alihue: 其實寫測試可以讓重構更快 07/02 15:24
64F：推 luke72: 菜鳥 程式出包責任是你扛還是前輩扛 別人扛責你幹嘛管 07/02 15:31
65F：→ luke72: 很多東西是有歷史因素的 沒搞清楚就亂重構容易出事 07/02 15:32
66F：→ shooter555: 重構者不繼續維護 然後接任者有起了重構的心 loop就出 07/02 15:34
67F：→ shooter555: 現了 07/02 15:35
68F：→ shooter555: *又 07/02 15:35
69F：→ shooter555: 現實中遇過因為架構上限制包含整個協議重構 結果重構 07/02 15:37
70F：→ shooter555: 後的東西太多問題不能用 省下重構時間想個新產品來玩 07/02 15:40
71F：→ shooter555: 說不定還比較好 07/02 15:40
72F：→ Darkword1987: 要改可以 出錯你扛 本來就是這樣了啊 07/02 16:31
73F：→ Masakiad: 每次都要把什麼擔責任加進來討論，重點就算有授權這邊也 07/02 16:55
74F：→ Masakiad: 一堆人搞不懂怎麼重構 07/02 16:55
75F：推 sharku: 爛 code 是造成 delay 跟 online issue 的元兇 07/02 17:10
76F：→ ssccg: 會動不就是對的? 不然還能叫會動嗎? 07/02 17:22
77F：→ ssccg: 不是重構要寫測試，是有測試比較好重構，沒測試你重構完了 07/02 17:25
78F：→ ssccg: 還不是要手動測好測滿? 07/02 17:26
79F：→ allenxxx: 測試之前也要先理解業務流吧,很多很奇特的你認為的狗屁 07/02 17:44
80F：→ allenxxx: 邏輯其實都是有歷史典故而且不得不做的,當特例變成客戶 07/02 17:45
81F：→ allenxxx: 常規,你要不要配合?那你看不懂自作聰明修了...保重 07/02 17:46
82F：→ bheegrl: 有些邏輯寫錯的改成對的是會出事的== 07/02 17:48
83F：推 vencil: 其實是本來就該測試了 不是等到重構才在想 07/02 18:18
84F：推 mpjp: 你又怎麼知道你寫的是對的XD 07/02 18:30
85F：推 hichcock: 先下手再說 07/02 18:47
86F：噓 xephon: 改成你以為的正確可能會出事 07/02 19:12
87F：推 Ekmund: 後來看前輩的操作是，把需求摸透，甚至說服上面的需求範 07/02 19:48
88F：→ Ekmund: 圍後，在還沒被授意前就硬幹前幾段提初步成果再說。 07/02 19:48
89F：→ Ekmund: 反正頭洗下去結果好看，頂頭多會給你試，要縮成本也不高 07/02 19:50
90F：→ foreverk: 那是你的前輩credit夠多可以燒，一般人先斬後奏的下場 07/02 19:52
91F：→ foreverk: 都不是太好 07/02 19:52
92F：推 devilkool: 推Masa大 07/02 21:03
93F：推 t64141: 我的操作跟E大前輩差不多，不過是先在本機做實驗樣品，覺 07/02 21:03
94F：→ t64141: 得可行再去說服上面後才會真的正式做/commit 07/02 21:03
95F：→ t64141: 或是趁著需求變更順便做效果也不錯 07/02 21:11
96F：→ GoodFriday: 小範圍重構免強睜一隻眼閉一隻眼說肉眼可判斷不會出錯 07/02 22:50
97F：→ GoodFriday: 大範圍重構還不寫測試是想? 07/02 22:51
98F：推 clamperni: 可憐哪 還在重構 07/02 22:54
99F：→ v7q4: 一池豬屎，好不容易經過時間的累積，終於表面乾掉不會臭，就 07/02 23:08
100F：→ v7q4: 沒必要去攪動它了！ 07/02 23:08
101F：→ Ghamu: 目前手上的程式連文件spec 都沒有 所以我隨便改沒差 07/02 23:49
102F：推 Nonegrame: 上班沒空寫測試 下班寫啊 就這麼簡單 07/03 00:24
103F：推 jasonwung: 你終究要作測試驗證，何不一開始就寫測試 07/03 00:32
104F：→ siriusu: 大家講的差不多了，測試就是幫助確認品質，而已經上線過 07/03 08:15
105F：→ siriusu: 的系統某種程度就是就過驗證的；所以不要偏離原本的行為 07/03 08:15
106F：→ siriusu: 是有價值的，就看這個價值對你來說有多少（系統多少人使 07/03 08:15
107F：→ siriusu: 用、是不是完全不能出錯的系統） 07/03 08:15
108F：推 bnd0327: 直接改下去，萬一發現改不好不是進退兩難? 07/03 10:27
109F：噓 InvincibleK: 長官沒說改,就別動嘿 07/03 15:06
110F：→ meowyih: 就算不說測試，你怎麼證明你寫的會比原來的好？你覺得你 07/03 20:51
111F：→ meowyih: 寫的比較好debug那只是因為是自己寫的啊，你走人後別人也 07/03 20:51
112F：→ meowyih: 會這麼認為嗎？顆顆 07/03 20:51
113F：→ Masakiad: 會啊，之後還請我做consultant 07/03 21:36
114F：推 APTON: 比較殘酷的是....說沒時間寫測試的，實際給了時間還是寫不 07/04 10:47
115F：→ APTON: 出來QQ 07/04 10:47
116F：推 play1921: 還沒有真的user勇敢改不要怕 有真的user就問問看pm 07/04 11:19
117F：噓 daddy29: 妳問題比較大 開發時程不夠兩件事 1.能力不足 2.看不清 07/04 11:42
118F：→ daddy29: 等級在哪邊 還想要重構 07/04 11:42
119F：推 lukelove: 嘻嘻 你確定你改完會比較好維護? 一堆越構越爛邏輯越複 07/04 12:03
120F：→ lukelove: 雜的例子 07/04 12:03
121F：推 stupid0319: 你的實力沒被認同才會被這樣說,只能靠你自己証明 07/04 16:23
122F：→ stupid0319: 如果你很強,怎麼做都是可行的 07/04 16:24
123F：→ panbanana: 要了解架構才能寫出好的，有意義的測項吧 07/04 17:22
124F：→ panbanana: 沒有了解，你能確定你的測法是正確的嗎 07/04 17:23
125F：推 mathrew: 因為你只是改成你認為正確的，事實上現在運作沒出大問題 07/05 12:18
126F：→ mathrew: 也許你寫出來的只是對你來說 你比較好debug 07/05 12:20
127F：→ mathrew: 因為是你寫的，所以你會知道問題在哪，但對別人來說不是 07/05 12:20
128F：→ Ghamu: 其實應該說清楚一點 本來程式一大球 好幾行 分崩離析 拆成 07/06 01:27
129F：→ Ghamu: 小分小分 即使有錯也比一整包天書好解決吧 07/06 01:27
130F：推 highwayshih: 啊人家就會動沒出錯 哪會比你沒寫測試重構出錯差? 07/06 07:25
131F：推 highwayshih: 爛code至少用能動說服大家它能用了 你連測試都不想寫 07/06 07:29
132F：→ highwayshih: 要怎麼說服別人重構會比較好? 07/06 07:29
133F：→ rodion: 原PO似乎弄錯測試程式的目的了? 測試是為了確保行為一致 07/06 17:20
134F：→ rodion: 輸出正確與否 不是測試程式應該著力的點 07/06 17:21