作者 michellehot (姆咪熱)標題 Re: [討論] 寫程式的追求?時間 Mon Mar 31 03:14:57 2025
專案要不要重構,因專案規模、時機、文化而異。
以下是根據我個人開發經驗的觀點:
我認為重構需要考量三個要點:動機、時機、理由。
1. 動機:為什麼需要重構
代碼畢竟是工具,不是文學,能帶來效益最重要。
要構成需求的強力條件是,安全性和耦合性。
當有具體新增功能需求的時候,修改原代碼容易導致錯誤風險提高。
當功能需要刪減的時候,原代碼無法快速拆分,且預期有多處時。
需要多方協作,而原代碼無法有效拆解,嚴重影響協同開放時。
代碼過於複雜導致難以維護。
代碼規模已經導致效能低落。
這些原因都是直接導致產品需求無法實現。
2. 時機:什麼時候該做
不為太遠的未來,而為不久的將來。
重構是為了可預見的功能拓展而做,不是為了不存在的以後而做。
當有功能拓展的可能性的時候,要規劃重構,避免技術債累積。
當產品需求和定位還不確定的時候,以最有效率開發的方式做。
舉例來說,開放解一元二次方程式的功能好了,
如果只是算法的一個步驟,直接一個函式搞定。
如果專案是要製作一個數學工具,那可重構可解N次的工具。
但如果動機是前者,卻去重構成後者,就不是對的時機。
3. 理由:巧立名目
重構的特點是不改變原本功能,所以通常不具功勞。
所以要配合具體產品需求再做。例如:
需要增刪改功能,需要重構不然做不到。
產品要做效能提升,需要重構不然會卡死。
專案需要開啟合作,需要重構不然無法協作。
專案需要交接給營運,需要重構不然難以維護。
不過通常交接了誰跟你重構,吃力不討好。
說白了,重構本質上是利他行為,願意做的都是好人。
好處不在增加功勞,而是提升管理效率這種隱藏成本,
也沒有一定要重構,而是取決於動機和時機,
取得一個有用和好維護的平衡。
至於要不要因為好讀或好看而重構,我覺得不值得。
代碼的原則歸原則、模式歸模式,滿足很好,只要不影響開發效率。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.232.100.61 (臺灣)
※ 作者: michellehot 2025-03-31 03:14:57
※ 文章代碼(AID): #1dwPWptV (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1743362099.A.DDF.html
※ 同主題文章:
Re: [討論] 寫程式的追求?
03-31 03:14 michellehot
→ marra: 不改沒事,一改出事,才是真的麻煩!1F 03/31 03:21
推 zyxx: 推 講得清楚2F 03/31 09:13
→ fatb: 有經驗的都知道改了超容易出事 一般底層別亂搞這種事情
高層改出錯可以主導整個重構事件找出問題 低層改出錯高層只會覺得案子這麼趕了你還在給我找麻煩3F 03/31 11:09
→ michellehot: 確實 不論是改上層還是底層 只要不是同一個人寫的
就很容易出錯 不過我想這可以是另一個主題了XD9F 04/01 00:42
推 aspirev3: 先把舊code增加測試如何11F 04/01 13:19
→ labbat: 樓上說得好,那麼誰來提供測資例子12F 04/01 20:56
--