作者:
Ghamu (貓丸)
2020-07-02 02:48:37想想這應該算是一種迷思吧
理論上是這樣沒錯
但事實上之前都沒寫測試了
你怎麼證明他之前是對的呢?
所以我大多都直接給他改下去
反正重構後東西也比較清楚
即使有錯 也比起蝦雞巴狗爛毛程式碼好除錯
之前前輩都說會動的程式碼不要去碰
然後就一球在那邊
我說要改 他就說
[啊你有寫測試嗎?]
開發時程又不允許
就一球在那邊越來越痛苦
會動的爛程式碼越來越多
不知道大家怎麼看
作者:
ousapas (komica123)
2020-07-02 04:01:00如果是老程式碼可以把手測流程自動化成functional test不用執著於一定要寫unit test如此一來不須要100% coverage也能安心重構
作者: keyboard56 (奇伯) 2020-07-02 07:25:00
證明他是對的這件事因為在正式環境運行一段時間了沒有使用者反應問題，基本上就是證明他沒錯
作者:
NDark (溺於黑暗)
2020-07-02 07:29:00不是證明是對的。是要證明改前後的輸出是一樣的。很多情況是函式Ａ寫錯除二 Ｂ只好跟著錯乘二 補回來這時候只重構Ａ或是只重構Ｂ都不能把錯誤"改正"因為無法確定是不是只有Ｂ會吃到Ａ的結果。
作者: keyboard56 (奇伯) 2020-07-02 07:32:00
全新的需求就可以跟使用者來回確認。重構跟開發全新需求是兩件事，你沒辦法在跟使用者去確認，所以你只能自己確認
作者:
alihue (wanda wanda)
2020-07-02 07:53:00好好寫不行嗎
好險你沒改到出包 哪天出包你就知道為啥前輩都放著不管了 嘻嘻
公司現在就能賺錢，為什麼要另外花成本重構？測試只是為了得出相同結果的手段，你的目的是想重構而不是減少測試。你要提出重構的效益說服pm、老闆，而不是前輩，老闆覺得重構好就會做了。
作者:
yyhsiu (hsiu)
2020-07-02 08:12:00覺得樓上說的非常中肯，各種教條要配合想要的結果跟手段盲從跟隨便說教條是迷思，而不看自己的情況、背後的理由都不太好
作者: hidog (.....) 2020-07-02 08:18:00
理性是要有測試再重構，但還是要考慮實務問題理想 打錯字
作者:
Csongs (西歌)
2020-07-02 09:14:00估開發時間就是要把測試考慮進去啊
作者:
allenxxx (fufuxxx)
2020-07-02 09:31:00你如果在開發團隊中夠力,可以去做,不然最好先找下一家有沒有想過你改了人家東西,原負責人拒絕維護誰會死你可以接下他的工作嗎?這行亂動不屬於自己的東西來配合自己想法,是大忌!
作者:
umum29 (....)
2020-07-02 09:38:00團隊若實行code review和ticket system 哪有不能改的程式我待過工廠IT也待過agile開發 製造業IT很符合樓上的說法
作者:
a926 (Aaron)
2020-07-02 10:36:00這是在釣魚？
作者:
Masakiad (Masaki)
2020-07-02 11:10:00程式對不對跟spec上怎麼定義有關，怎麼會跟有沒有測試有關？一開始的核心概念沒搞懂你才會問這樣的問題
說的很對，反正績效算你的，技術債上門時大概也升官跳槽了
作者:
brucetu (sec)
2020-07-02 12:39:00反正改壞了出包你負全責不要推託說原本的code很爛那你愛怎麼改都可以
寫測試也要懂以前的邏輯脈絡，但會重構就是以前的程式混雜一起到最後大家都不想補技術債，只想亂寫，然後bugfix在丟給菜鳥亂補
作者:
Csongs (西歌)
2020-07-02 12:52:00真的很少接到舒服的code
把這時間省下來 刷leetcode、練英文比較實在
作者:
deray (Deray)
2020-07-02 13:36:00工啥小啦幹
作者:
Masakiad (Masaki)
2020-07-02 13:56:00推文看下來覺得這些系統真的很堪憂阿
作者:
cphe (魔鬼藏在垃圾筒裡)
2020-07-02 14:00:00這老議題了...
作者:
NTULioner (LionsHeart)
2020-07-02 14:20:00工作不要出包最重要改好 上面不覺得有功 改爛馬上變戰犯
就是遇過有人說要重構 然後也重構了 結果一堆bug又不修 然後只好等下一個人來重構loop?
作者:
Masakiad (Masaki)
2020-07-02 15:01:00樓上，所以才要先寫測試後才重構，然後重構目標跟debug完全不同，怎麼回有bug結果又重構這種操作？
作者:
alihue (wanda wanda)
2020-07-02 15:24:00其實寫測試可以讓重構更快
作者:
luke72 (ccc)
2020-07-02 15:31:00菜鳥 程式出包責任是你扛還是前輩扛 別人扛責你幹嘛管很多東西是有歷史因素的 沒搞清楚就亂重構容易出事
重構者不繼續維護 然後接任者有起了重構的心 loop就出現了*又現實中遇過因為架構上限制包含整個協議重構 結果重構後的東西太多問題不能用 省下重構時間想個新產品來玩說不定還比較好
作者:
Masakiad (Masaki)
2020-07-02 16:55:00每次都要把什麼擔責任加進來討論，重點就算有授權這邊也一堆人搞不懂怎麼重構
作者:
sharku (明珠求瑕)
2020-07-02 17:10:00爛 code 是造成 delay 跟 online issue 的元兇
作者:
ssccg (23)
2020-07-02 17:22:00會動不就是對的? 不然還能叫會動嗎?不是重構要寫測試，是有測試比較好重構，沒測試你重構完了還不是要手動測好測滿?
作者:
allenxxx (fufuxxx)
2020-07-02 17:44:00測試之前也要先理解業務流吧,很多很奇特的你認為的狗屁邏輯其實都是有歷史典故而且不得不做的,當特例變成客戶常規,你要不要配合?那你看不懂自作聰明修了...保重
作者:
vencil (vencs)
2020-07-02 18:18:00其實是本來就該測試了 不是等到重構才在想
作者: mpjp (mpjp) 2020-07-02 18:30:00
你又怎麼知道你寫的是對的XD
作者:
hichcock (快樂一整年 ^^~~~)
2020-07-02 18:47:00先下手再說
作者:
xephon 2020-07-02 19:12:00改成你以為的正確可能會出事
作者:
Ekmund (是一隻小叔)
2020-07-02 19:48:00後來看前輩的操作是，把需求摸透，甚至說服上面的需求範圍後，在還沒被授意前就硬幹前幾段提初步成果再說。反正頭洗下去結果好看，頂頭多會給你試，要縮成本也不高
那是你的前輩credit夠多可以燒，一般人先斬後奏的下場都不是太好
作者: t64141 (榕樹) 2020-07-02 21:03:00
我的操作跟E大前輩差不多，不過是先在本機做實驗樣品，覺得可行再去說服上面後才會真的正式做/commit或是趁著需求變更順便做效果也不錯
小範圍重構免強睜一隻眼閉一隻眼說肉眼可判斷不會出錯大範圍重構還不寫測試是想?
作者:
v7q4 ((．)(．)乳劍雙修 -|＝＞)
2020-07-02 23:08:00一池豬屎，好不容易經過時間的累積，終於表面乾掉不會臭，就沒必要去攪動它了！
作者:
Ghamu (貓丸)
2020-07-02 23:49:00目前手上的程式連文件spec 都沒有 所以我隨便改沒差
作者:
Nonegrame (程式寫得好，好人做到老)
2020-07-03 00:24:00上班沒空寫測試 下班寫啊 就這麼簡單
作者: jasonwung (路人JJ) 2020-07-03 00:32:00
你終究要作測試驗證，何不一開始就寫測試
作者:
siriusu (かがみは俺の嫁。)
2020-07-03 08:15:00大家講的差不多了，測試就是幫助確認品質，而已經上線過的系統某種程度就是就過驗證的；所以不要偏離原本的行為是有價值的，就看這個價值對你來說有多少（系統多少人使用、是不是完全不能出錯的系統）
作者:
bnd0327 (阿噗噗)
2020-07-03 10:27:00直接改下去，萬一發現改不好不是進退兩難?
作者:
meowyih (meowyih)
2020-07-03 20:51:00就算不說測試，你怎麼證明你寫的會比原來的好？你覺得你寫的比較好debug那只是因為是自己寫的啊，你走人後別人也會這麼認為嗎？顆顆
作者:
Masakiad (Masaki)
2020-07-03 21:36:00會啊，之後還請我做consultant
作者:
APTON (瑋瑋)
2020-07-04 10:47:00比較殘酷的是....說沒時間寫測試的，實際給了時間還是寫不出來QQ
還沒有真的user勇敢改不要怕 有真的user就問問看pm
作者: daddy29 (願上帝與你同在) 2020-07-04 11:42:00
妳問題比較大 開發時程不夠兩件事 1.能力不足 2.看不清等級在哪邊 還想要重構
作者: lukelove (午睡) 2020-07-04 12:03:00
嘻嘻 你確定你改完會比較好維護? 一堆越構越爛邏輯越複雜的例子
你的實力沒被認同才會被這樣說,只能靠你自己証明如果你很強,怎麼做都是可行的
要了解架構才能寫出好的，有意義的測項吧沒有了解，你能確定你的測法是正確的嗎
作者:
mathrew (Joey)
2020-07-05 12:18:00因為你只是改成你認為正確的，事實上現在運作沒出大問題也許你寫出來的只是對你來說 你比較好debug因為是你寫的，所以你會知道問題在哪，但對別人來說不是
作者:
Ghamu (貓丸)
2020-07-06 01:27:00其實應該說清楚一點 本來程式一大球 好幾行 分崩離析 拆成小分小分 即使有錯也比一整包天書好解決吧
啊人家就會動沒出錯 哪會比你沒寫測試重構出錯差?爛code至少用能動說服大家它能用了 你連測試都不想寫要怎麼說服別人重構會比較好?
作者:
rodion (r-kan/reminder)
2020-07-06 17:20:00原PO似乎弄錯測試程式的目的了? 測試是為了確保行為一致輸出正確與否 不是測試程式應該著力的點