※ 引述《sec5566 (sec)》之銘言：
: 或是命名規則有問題的，
: 像函式用大駝峰，類別用小駝峰，
: 或很奇怪的名稱之類，
: 不然就是排版很亂的，
: 這種大家會手癢去改嗎？
就跟推文鄉民講的一樣 這是團隊的管理問題
通常命名如果不符規則 只是改大小寫這應該不用過問吧
但是改名稱 老實講這要看寫的人還在不在職啦
不然你改了 code review時解釋說: 這名稱很奇怪
除非你跟對方溝通過 或你比對方大牌
做事做就是做人 沒有對事不對人的
(何況 你有辦法保證你的命名一定比較好？)
: 改下去又是大工程了，結果工作越做越多
你前面講dry原則的 軟體開發原則很多 但這些原則多半都被有心人士拿來吵架用
更何況 這些原則能不能為商品帶來價值 多數都不能
我建議三小原則的 放在自己心中默默實踐就好
我講一下重構的幾個種類 這是小弟我在業界的觀察
1. 命名、拆解
這就是clean code裡很基本的東西
function不要太長 命名清晰描述單一動作
改名的事情我前面說過了 這邊就不贅述
IMO 比起改錯字、大小寫 他命名很奇怪我把他改掉
把大function拆解成小function 還比較有用
(而且絕對不會是大工程... 所以... 要實踐你所謂的dry可以從小事做起)
2. 運用語言技巧 精簡程式碼
老實講這種事情就只是單純的炫技
小弟我就曾經把一大段大量重複的code
利用Template 將邏輯拆解成Policy
使得每個重複的流程都可以透過組合的形式避免duplicated
但說真的 它的價值就只有文學上的價值而已
(我認為在某些狀況下 重複的code不見得是錯誤或不良的)
3. 架構
我認為需要改架構的狀況只有幾種：
a) 邏輯紊亂重複 導致效能低落或維護不易
b) 當前的架構無法因應新的需求或改變
這種狀況 才是你所說的工程浩大
不然一般狀況下的重構搬移刪除重複代碼都只是很基本很淺的功夫
TL;DR
其實重點是這樣的
在這個業界 有需求 滿足需求才會產生價值
你的需求 如果只能滿足你個人 那我肯定你做的事情是沒啥幫助的
更何況 你重構又怎麼能保證不會有新的問題產生
所以最好的方式是 建立測試 才去重構
而不是重構自己爽完了 留給後人收拾問題
小弟上次重構 把一個重點功能的速度提升至少2.5倍
還贏得了與某大公司進一步合作的機會 給你參考