根據 D02 - 程式碼寫作範式的歷史 脈絡發展，我們可以說

程式碼寫作範式就是多個規則或理念的集合

既然他們是集合，那我們就可以看到他們的交集、聯集，甚至在座標系統上把他們視覺化。不過要建立座標系統的話，該選擇那些座標軸呢 ?

不知道大家有沒有注意到，喜歡 FP 的人總是自豪自己用宣告式的方式寫程式，喜歡 OO 的人則特別注重封裝，而分析這兩個特性我發現他們其實是從兩個方向來把可能變得很冗雜的程式碼抽象化

封裝 > 行為與狀態的抽象化 > 空間上的抽象化 (spatial abstraction)
例如「四隻腳、一根尾巴、兩個眼睛、會汪汪叫」
是「一隻小狗」

宣告式 > 流程的抽象化 > 時間上的抽象化 (temporal abstraction)
例如「民宿走到兩國，搭大江戶線到上野，搭新幹線到輕井澤」
是「前往輕井澤」

根據這兩種抽象化的方式建立座標軸，我們就得到了下面這一張圖

抽象化的好處有很多，首先是可讀性，有經驗的開發者能用更短的時間理解更多的程式碼內容；再來是可觀察性，要準確診斷錯誤發生在哪裡這件事，本身就需要程式碼有高度的抽象化，如果只知道「幾點幾分，某個節點發生錯誤」，這樣 debug 起來是很累的，更別說要自動修復了，所以一年前的我即使在工作上也很努力地朝座標圖左下角前進。

然而現實告訴我 高度抽象化也是有成本的。越高度的抽象化，代表越陡峭的學習曲線。要使用新的技術就會用到新的框架、函式庫甚至新的語言，而這些全部都需要學習成本。除了學習成本，溝通也需要成本，要把這些事情的價值讓老闆、同事、甚至客戶理解真是件超級困難的事情。

所以在工作上選擇所要使用的技術時建議多考量幾個方面，包含

• 要解決的問題 (真的遇到困難或問題足夠複雜再掏出這些技術來解決)
• 相關人員的接受度 (老闆、同事、PM、後續接手的團隊...等)
• 開發的時程

既然工作上不太用得到，為甚麼要學這些呢? 至少就我來說有這些理由

• 自我滿足
• 能很快速的進入精神時光屋

  參考《心流》，真正的幸福感來源於全身心的專注與投入

• 體感上比較快下班

參考文獻

• 怎样理解“组合优于继承”以及“OO的反模块化”，在这些方面FP具体来说有什么优势？
• Encapsulation is not information hiding
• 為什麼要學 Functional Programming?
  (這篇除了文章本身以外，下面 Mike/良葛格兩位大神的留言也讓我獲益匪淺)

附註

• 座標圖中的程式碼寫作範式只是我有所認識的，不是全部，不一定具有代表性，範圍也不一定準確，僅供參考。有任何建議歡迎留言告訴我，我會用最快的速度回覆並修正。
• 接下來兩天預計會簡單的介紹上圖中的幾種程式碼寫作範式，以及把他們這樣擺放的原因。