Functional Programming 中文譯作函式程式設計，或是功能性程式設計，常簡稱為：FP，是一種透過使用純函式（Pure Funciton）進行軟體開發，且避免副作用的程式設計典範，比起宣告式的流程控制，在 FP 採用主要以表達式的方式撰寫程式碼。
如果我們將 FP 這個設計典範的特點一一列點出來會有以下概念：
- 透過純函數（Pure Function）將函式封裝成函式最小單位
- 使用複合函數（Function Composition）提升函式的復用性
- 避免副作用（Side Effect）
- 使用表達式
什麼是純函式？
純函式（Pure Funciton）在 FP 中是一個很核心的概念，在 FP 這個設計典範中，我們都會使用純函式的方式來撰寫我們的程式碼。
首先讓我們來看看純函式的定義：
- 單輸入單輸出（One input, one output）
- 不會造成任何副作用
那我們為什麼在 FP 中要使用純函式呢？我們希望可以讓程式碼的狀態不互相依賴，以免造成變數與變數間互相覆蓋的狀況。
更重要的是，我們同時也希望程式碼的覆用性可以更高，而不是在同個函式中，同時處理不同性質的任務，一旦這些任務重複性出現在不同的流程中，就會發現任務彼此之間過於耦合難以拆分，要擴充新的功能，就只能向樂高一樣繼續往上疊，或一改就要改到天荒地老的窘境。
除了開發過程可能變得沒有效率外，把程式碼當樂高疊的後果是，萬一未來有人不小心改到了某個地方，就很容易導致這個程式碼樂高塔輕易崩塌。
在 FP 中，我們傾向把任務拆分成最小最小的單位，並且透過函式來處理這些任務，而規則單純卻又嚴謹的純函式就成為 FP 最萬用的工具。
如果我們要寫一個簡單、但卻會重複出現的篩選邏輯，例如：將指定商品進行打折，沒有使用 FP 前我們可能會這樣寫：
或者是：
上述這些程式碼會有幾個狀況：重複程式碼、函式內一次性做太多事，如果我只要取得指定商品的打折價，就必須再計算一次，或是取得其他商品的打折數，這樣就很容易產生副作用，甚至是預期外的結果。
現在我們使用純函式寫一個打折器：
這樣是不是乾淨許多呢？除了純函式外，在 FP 中我們還會使用另外一個工具：「柯里化」來管理我們的程式碼。
什麼是「柯里化」？
其實最初科里化（Currying）是一個數學理論，後續才由 Haskell Curry 發揚光大，故名「Currying」。
科里化的核心概念是將函式要帶入的多個參數，轉換為一次性帶入一個參數，舉例來說：
這麼做有什麼好處呢？讓我們來看看科里化與純函式相比有什麼好處：
- 可以把程式法切的更碎片，提高複用性，例如：可以固定第一個、第 n 個參數的值，根據需求將關注點放在需要放的地方。
- 因為一次只傳入一個參數，降低傳入參數數量的錯誤
難道上述兩個優點純函式做不到嗎？是的純函式還真的做不到，讓我們直接來看範例比較：
我們會發現若是透過純函式固定第一個參數，其實沒什麼意義，因為我們還是會不斷重複帶入同樣的參數，光是上方的程式碼，就足以想見未來若是要重複使用函式，未經科里化的純函式程式碼會越來越多。
以上就是 FP 設計典範中最基礎也是最廣為人知的概念，不過 FP 的概念不僅僅於此，如果你有興趣的話，可以參考我在 2022 第十四屆 iThome 鐵人賽《致 JavaScript 開發者的 Functional Programming 新手指南》。
在這系列文章中，除了介紹 Functional Programming 這門設計典範外，也包含了要習得 FP 技術前所必備的 JavaScript 基礎知識，及一些 FP 在前端的演進史。
希望透過這篇文章的分享，可以讓大家簡單了解那些前端開發者常說的 Pure Function 及 Curry 是什麼，關於 Functional Programming 你有什麼想要跟我分享的嗎？歡迎下方留言與我分享！
希望今天的文章有幫助到正在閱讀的你，如果你喜歡我的文章的話，可以留下你的愛心或是收藏我的文章，也或者可以點選「贊助」，你的一杯咖啡絕對是我持續寫下去的動力！或是透過拍拍手，用你小小的行動支持我的創作！
我是Vivian，我們下次見。
關於我：
一名從英文系畢業的前端工程師，喜歡閱讀、寫東西及自我成長。
｜Instagram: Vivian Yeh｜vivian_enlife
｜聯絡我：vivian.enlife@gmail.com