專案要不要重構，因專案規模、時機、文化而異。
以下是根據我個人開發經驗的觀點：
我認為重構需要考量三個要點：動機、時機、理由。
1. 動機：為什麼需要重構
代碼畢竟是工具，不是文學，能帶來效益最重要。
要構成需求的強力條件是，安全性和耦合性。
當有具體新增功能需求的時候，修改原代碼容易導致錯誤風險提高。
當功能需要刪減的時候，原代碼無法快速拆分，且預期有多處時。
需要多方協作，而原代碼無法有效拆解，嚴重影響協同開放時。
代碼過於複雜導致難以維護。
代碼規模已經導致效能低落。
這些原因都是直接導致產品需求無法實現。
2. 時機：什麼時候該做
不為太遠的未來，而為不久的將來。
重構是為了可預見的功能拓展而做，不是為了不存在的以後而做。
當有功能拓展的可能性的時候，要規劃重構，避免技術債累積。
當產品需求和定位還不確定的時候，以最有效率開發的方式做。
舉例來說，開放解一元二次方程式的功能好了，
如果只是算法的一個步驟，直接一個函式搞定。
如果專案是要製作一個數學工具，那可重構可解N次的工具。
但如果動機是前者，卻去重構成後者，就不是對的時機。
3. 理由：巧立名目
重構的特點是不改變原本功能，所以通常不具功勞。
所以要配合具體產品需求再做。例如：
需要增刪改功能，需要重構不然做不到。
產品要做效能提升，需要重構不然會卡死。
專案需要開啟合作，需要重構不然無法協作。
專案需要交接給營運，需要重構不然難以維護。
不過通常交接了誰跟你重構，吃力不討好。
說白了，重構本質上是利他行為，願意做的都是好人。
好處不在增加功勞，而是提升管理效率這種隱藏成本，
也沒有一定要重構，而是取決於動機和時機，
取得一個有用和好維護的平衡。
至於要不要因為好讀或好看而重構，我覺得不值得。
代碼的原則歸原則、模式歸模式，滿足很好，只要不影響開發效率。

不改沒事，一改出事，才是真的麻煩！

推 講得清楚

有經驗的都知道改了超容易出事 一般底層別亂搞這種事情高層改出錯可以主導整個重構事件找出問題 低層改出錯高層只會覺得案子這麼趕了你還在給我找麻煩

推

推

覺得解N次方程式的例子不錯

確實 不論是改上層還是底層 只要不是同一個人寫的就很容易出錯 不過我想這可以是另一個主題了XD

先把舊code增加測試如何

樓上說得好，那麼誰來提供測資例子

推推

測資當然是想重構的人想辦法

重構成一坨 也可以再重構一次 工作永動機

呃...要改的東西太多了，那就改天吧

不是所有人都精通的，有重構專業的不一定有測資專業呀

真的要做好重構很精實 但是事倍功半 只是自己的修行

推

推