以前對於重構的觀念
都是偏細節上的討論
例如怎麼優化原本的程式碼
去掉重複，職責分離等等

直到最近跨團隊進行討論時
才知道除了優化程式碼
重構背後還有更重要的目的

事情的起頭是
有一個緊急的需求
為了快速開發
有人覺得應該開新的專案
但有人覺得應該整合在舊的系統
而不是維護兩套

先說結論
最後因為時程的考量
還是開新的專案
但是在之後
會看功能的成效如何
成效不好，就直接把新專案砍掉
成效好，就把兩個專案合併起來

有了結論之後
部門主管分享對於這件事情的看法

早年公司剛成立的時候
人來來去去
新的人看不懂，
或是看不順舊有的程式碼
最快速解決的方式
就是再開一個新的專案
來解決新的需求

優點的話很明顯
就是開發快速
開發人員開心
畢竟大家都比較喜歡自己的程式碼
不喜歡維護別人的

不過缺點也顯而易見
就是同一種類的功能
可能散落在多個專案之中

例如要換廣告橫幅
就要去三個後臺系統
才能替換所有的廣告

久而久之
就會發現許多專案
其實在做類似的事情
工程師必須維護大量專案
而操作人員也必須了解多種系統

所以公司才鼓勵重構
而不是重寫
為的就是讓老舊的系統
能夠慢慢變得更好
而不是不斷的開新專案
來解決新的需求

聽完這次討論
對於重構更多一層次的理解
也提醒自己
在重寫之前
思考是否先能重構