事情是這樣的
小弟最近接到使用者需求
要增加幾個跟之前很像的功能
舊的那隻程式已經歷經許多測試 目前正穩定的運作中
但最初的需求很單純
因此設計得不是很有彈性 不利於擴充及更改
第一次接到需求的時候
我想了一下覺得重構有點麻煩
於是直接複製了一份然後改了需要改的地方
變成兩隻有八成像的程式 各做各的
但最近又要再增加一個
於是我開始猶豫該不該整個打掉重構
避免程式碼繼續這樣擴張下去 感覺很不專業
之後再有需求也比較好調整
但如果複製改一改大概只要一個小時
打掉重構可能要一個禮拜 還不保證會不會有甚麼多出來的bug
想請教大家在類似的情況
都用哪些標準來決定甚麼時候應該重構

上面看你沒事找事做的時候

做事情是這樣 如果你覺得某些事你這樣做可以省到後面很多時間你可以做 但實際效果沒有符合預期/有機會搞砸/婊到別人/自己扛責/你沒有你想像中的專業有把握 你就不該隨便亂動已經跑的很穩定的東西還有不要用感覺來判斷專不專業 應該要仔細分析優缺點再來抓一個正確的作法

沒事做的時候

你的狀況應該是因為沒寫測試案例才會覺得重構容易有bug

維護越來越痛苦的時候

寫久了都會有感覺哪邊是應該要事先提出來復用的部分，很不科學但是真的是很吃肌肉記憶抽象一點的說就是會自動分類可變動與不可變動的部分吧

千萬不要refactor 除非你吃飽了沒事幹

然後不要習慣複製貼上改一行，很可怕

看了上面一堆人排斥重構 就知道台灣軟體業只會繼續腐爛

重構是持續進行的 比如你現在這時候遇到這狀況 就要拉正，而不是持續放任歪樓

重構這種事有時根本就舉手之勞而已 順手改一點改一點老實說 會不會想去重構 跟工程師自身的修養有很大的關係你夠不夠認真看待你的專業 就決定你對重構的態度回到現實面 你要重構當然要跟上級討論並且獲得許可及時間如果上面管理方都同意 你當然應該要開始重構但這件事應該是由工程師自己發現問題 並主動向上面提出

最討厭維護複製貼上一堆相似程式，然後同樣邏輯要改漏東漏西的

如果上面死都不願給時程 那你還有藉口讓它放著爛沒關係

造成後人不便，自己也常埋地雷的程式片段

而不是聽到要改Legacy就避之為恐不及

大部分只會重建不會重構。

我講的是態度方面 至於執行細節 原本Legacy連測試都沒 怎麼改 嚴格來說都不算是重構就是了 XD

離職前

" target="_blank" rel="nofollow">

推文就推文 推一張圖幹嘛？

字太多有時會被切斷跳行

一堆人排斥重構，然後又嫌台灣軟體業爛反正到最後也是牽拖到老闆，不檢討自己市面上很多重構的方法，包含寫完整的測試與ci/cd，確定你在可控的風險下重構。不重構只會讓後人東補西補，踩地雷讓台灣的軟體缺一個比一個還屎

重構沒那麼簡單 做得好沒人理 出錯被釘到死這是政治問題 不是軟體問題

新學到東西然後想起過去的code寫得有夠爛時

打掉重練政治問題比較多，做久就知道為什麼，有時候不是你想做就有辦法執行除非上面決策的人打從心裡想這麼做

重構最基本要有明確的spec

想離職時

重構是一群小修改的集合...稍微抽出method或rename都算https://martinfowler.com/books/refactoring.html雖然繁中譯本已經絕版，但簡體書大家也可以加減看一下作者就是定義重構的人Its essence is applying a series of smallbehavior-preserving transformations, each of which"too small to be worth doing".

我是會考慮重構對我是否Z>B 如果以後能省很多時間我就會重構 而不是以公司角度考量

政治的確才是真正的問題 但我上面在說的是工程師本身的態度一堆人就是寧可放在那邊爛也不想去動 甚至上面給你時間叫你改你都千推萬推找一堆藉口 這種就是垃圾 軟體界的毒瘤你想重構但上面不給你時間和資源那就算了阿 至少你提過了有想要重構的態度出來就行了 至少在這種心態下 你新產出的程式不會差到哪裡去 因為過去的垃圾你都看不順眼了但如果懶得去管過去垃圾 那非常有可能未來也是繼續出垃圾

重構很難？

沒有人排斥重構 是你本不該就隨便亂動已經final的code 這種都是團體內有共同共識考量到長期維護同案/持續上線營運的才會慢慢修改 你一人專案或完全你負責要怎樣改都是你的事只要是在合理的時間範圍完成你要自high/練功都行重構都是會發生在有必要做的時候 而有必要做的時機是在你真的有看到明確的問題時候你知道怎麼改比較正確 跟獲得更大效益不是你在那裡自high想改就在那裡下刀動手小弟做系統幫專案做重構改了數百組核心也寫了數百組測試不知道這個心得不知道夠不夠格上次一位只是改個function覺得沒問題也測過了上線直接當天飛起來 你以為沒壓力啊

加薪的時候

我剛好朋友也有主力的產品 一個系統的營收是用千萬在計算 開個 Basecamp 看到滿滿記載要重構的地方 都是有原因跟理由的真的從來沒看過用感覺在做事 幹這件事的人已經飛上去了(上述那位）

需要花多久時間才是重點

要離職的時候，重構爆掉就不用救了

隨時

cp改一改就好了 別沒事找事 沒人會感謝你的

退休後

神明託夢說改就改

有把握不會出包的話我會重構

舊的不動，新的慢慢寫，然後拿之前的test跑三次確定沒問題後才拿出來

自己的扣才會 別人的扣一不小心沒用好 自找麻煩

重構有很多層次 只是約分/提出一個共用的func 也算重構將某變數或函式 rename成比較有意義看得懂的名稱也是重構將重覆出現的字串 改成const variable來使用也是重構雖然都是小小的整理 都算是重構, 也都需要進行測試

長官看你都準時下班的時候

既然你會猶豫,那就是想得不夠徹底,想到你決定要做(或不要),那就對了

Never

吃飽太閒? 自己開個branch去玩啦

你想要長期領養這隻野貓的時候你就會想為他洗澡

打掉就不是重構了 那是重練

複製一份

大程式重構...？呵呵