抽象與重用的代價

曾經有一段時期我非常熱衷把重複使用的程式碼抽象成函式，尤其當時我正開始學習 Functional Programming，那更是瘋狂，各種在抽象再抽象、重用再重用，彷彿只要把程式碼作抽象就能讓程式到達另一個境界。

但隨著時間的推移，程式確實到另一個境界了，一個我看不懂的境界，我開始意識到，當下認為所謂好的抽象與重用對未來並不是好的，有時反而會變成日後改動的瓶頸，甚至到改不動的地步。

如果原本就是一坨義大利麵，那強制抽象與共用只會變成更大坨的義大利麵，然後這坨義大利麵間接影響了所有使用它的地方，整個修改難度又增加了。

經驗的積累讓我重塑了我對抽象的想法，更仔細的分析程式碼不同面向：

• 該函數核心目的是什麼
• 邏輯面來說是否是長期不變的
• 以使用情境來預測是否各功能走向會越來越分歧
• 如何設計參數能夠減少日後擴充的難度

我們都知道你想把綜合果汁變回原來的水果是不可能的，當然程式碼並沒有到這麼極端，用紅綠豆來比喻更適合，你把已經混合的紅豆綠豆分開遠遠比你把紅豆跟綠豆混在一起還要難的多，如果是紅豆跟湯圓混在一起，或許分開還比較容易一些。

所以在抽象之前請務必看清楚，你要混的是綠豆跟紅豆，還是紅豆跟湯圓，假如日後不幸要分開了，那這會直接影響你修改的難度。