專案要不要重構，因專案規模、時機、文化而異。 以下是根據我個人開發經驗的觀點： 我認為重構需要考量三個要點：動機、時機、理由。 1. 動機：為什麼需要重構 代碼畢竟是工具，不是文學，能帶來效益最重要。 要構成需求的強力條件是，安全性和耦合性。 當有具體新增功能需求的時候，修改原代碼容易導致錯誤風險提高。 當功能需要刪減的時候，原代碼無法快速拆分，且預期有多處時。 需要多方協作，而原代碼無法有效拆解，嚴重影響協同開放時。 代碼過於複雜導致難以維護。 代碼規模已經導致效能低落。 這些原因都是直接導致產品需求無法實現。 2. 時機：什麼時候該做 不為太遠的未來，而為不久的將來。 重構是為了可預見的功能拓展而做，不是為了不存在的以後而做。 當有功能拓展的可能性的時候，要規劃重構，避免技術債累積。 當產品需求和定位還不確定的時候，以最有效率開發的方式做。 舉例來說，開放解一元二次方程式的功能好了， 如果只是算法的一個步驟，直接一個函式搞定。 如果專案是要製作一個數學工具，那可重構可解N次的工具。 但如果動機是前者，卻去重構成後者，就不是對的時機。 3. 理由：巧立名目 重構的特點是不改變原本功能，所以通常不具功勞。 所以要配合具體產品需求再做。例如： 需要增刪改功能，需要重構不然做不到。 產品要做效能提升，需要重構不然會卡死。 專案需要開啟合作，需要重構不然無法協作。 專案需要交接給營運，需要重構不然難以維護。 不過通常交接了誰跟你重構，吃力不討好。 說白了，重構本質上是利他行為，願意做的都是好人。 好處不在增加功勞，而是提升管理效率這種隱藏成本， 也沒有一定要重構，而是取決於動機和時機， 取得一個有用和好維護的平衡。 至於要不要因為好讀或好看而重構，我覺得不值得。 代碼的原則歸原則、模式歸模式，滿足很好，只要不影響開發效率。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.232.100.61 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1743362099.A.DDF.html 推 Kroner: 關節痛就老人病 03/31 11:11推 Chricey: UC2推薦？有人試過嗎？靠譜嗎？ 04/01 00:42推 Kroner: 我也有過關節痛的經驗，真的超痛苦的啦！推薦去看醫生，早點處理比較不會拖延變嚴重。 04/01 23:19推 Kroner: 關節痛有沒有辦法完全根治啊？UC2聽起來像萬靈丹 04/02 15:41