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