Udi Dahan

一個新手的故事#

作者回憶他第一份工作的經歷：剛拿到學位，急於證明自己，每天加班研讀現有程式碼。開發第一個功能時，他格外小心地將所學付諸實踐——註解、日誌記錄，並將共用程式碼抽取到函式庫中。然而，在 code review 時，他精心準備的「重用」卻被潑了冷水。

被忽略的關鍵：上下文#

在大學裡，**重用（reuse）**被奉為軟體工程的典範。教科書、文章、教授——所有人都說重用是正確的做法。那為什麼會出錯？

答案是：上下文（context）。

系統中兩個截然不同的部分恰好執行相同的邏輯，這不代表它們之間有真正的關聯。在抽取共用函式庫之前，這些部分彼此獨立，可以各自演進，各自根據業務環境的變化調整邏輯。

那幾行看起來相似的程式碼，可能只是時間上的巧合——一個偶然的相似，而非真正的重複。

過度共用的代價#

當你把偶然相似的程式碼硬是抽成共用元件時：

• 原本獨立的模組變得耦合（coupled）
• 一個模組的變更可能影響另一個不相關的模組
• 各模組失去了獨立演進的能力

在決定共用程式碼之前，先問自己：這些相似之處是本質上的重複，還是只是偶然的巧合？只有真正的重複才值得抽取。