Grokking Simplicity FP CH1 ~ CH3

[steven4program]

《簡約的軟體開發思維：用 Functional Programming 重構程式》CH1 - CH3

簡報連結

20250410

導讀人：Lois
筆記工：Steven

---

第一章 初識函數式程式概念

• 函數式程式設計

  • 使用數學函式與避免 Side Effect 為特色的程式設計方法

• Side Effect 定義：一個函數在計算過程中除了返回一個值之外，還對外部產生了影響。這裡的外部可以包括修改全域變數、寫入檔案、發送網路請求、發送電子郵件，甚至是更新用戶界面等。簡單來說，如果一個函數在運算時除了計算結果外，還改變了其他部分的狀態，那麼這個函數就有副作用。

• 實務中 FP 仍需要 Side Effect，這些 Side Effect 是我們使用軟體的根本原因

區分 Actions, Calculations 及 Data

FP Programmers 會把程式碼分成 Actions, Calculations 及 Data

• Actions: 執行結果會因為不同時間點或次數而有所不同

sendEmail(to, from, subject, body) // 寄送電子郵件
saveUserDB(user) // 儲存資料到資料庫
getCurrentTime() // 每次呼叫，傳回的時間都不一樣

• Calculation: 不管在何時或執行多少次，只要輸入不變，輸出都會相同

sum(numbers) // 快速求出一串數字的總和
string_length(str) // 輸入相同字串，回傳的字串長度值永遠相同

• Data: 資料可紀錄與事件有關的事實

{"firstname":"Eric", "lastname": "Normand"} // 關於某人的資訊
[1, 10, 2, 45, 3, 98] // 單純的數字串列

區分的好處

• 今日大多數軟體開發都採分散式系統，而這正是 FP 擅長之處，而 FP 並不是新風潮，而是一種老牌的程式設計方法。

• 分散式系統的三項特徵：

  1. 訊息不按順序抵達
  2. 同樣的訊息可能被傳送 0, 1 或者更多次
  3. 在未收到回音的情況下，無法知道系統發生了什麼事

• FP Programmers 喜好 Data > Calculations > Actions，因為 Actions 在不同的時間跟執行次數會產生不同的節果，所以盡量將 Action 拆分為 Calculation 或 Data，可以降低程式執行中的不確定性，尤其是在複雜的分散式系統架構下。

• FP 的經典定義較適用於學術界，仍未有適合軟體工程的定義，因此很多人的印象是既抽象又不切實際。本書著重於 FP 的實務面而非學術面的解釋

第一章總結

1. 什麼是 Actions？
2. 什麼是 Calculations？
3. 什麼是 Data？
4. 可以用 是否會產生 side effect 的函式 來分別 Actions 及 Calculations

---

第二章 實務中的函數式思維

以經營 Toni's Pizza 披薩店來介紹 FP 概念，FP Thinking 可分為兩層：

1. 區分 Actions, Calculations 及 Data

• Actions
  • 擀麵團
  • 送披薩
  • 進原料
• Calculation
  • 準備食譜
  • 列採購清單
• Data
  • 庫存清單
  • 披撒食譜
  • 客人的點餐資訊
  • 收據

2. 使用頭等抽象化 (First-class abstraction)

• 披薩店的廚房由多個機器人掌廚，因此是個分散式系統
• 頭等函式 (First-class Functions) 定義: 接收其他 Functions 作為參數的 Functions
  1. Toni 把所有流程畫成一張時間線圖，但是發現這樣做太慢
  2. 採用分散式系統做法，把工作分為三個部份：擀麵團、做醬料、切起司
  3. 各個工作流程的順序不一定，導致會有失敗的成品產生 (in wrong order)
  4. 於是 Toni 切分時間線圖，讓這三個工序都完成了才進行後續步驟
• 使用頭等函式協調多個機器人，以擴大烘烤的規模

分層設計 (Stratified Design)

• 上層至下層的順序：營業規則(決定去哪裡買原料) => 領域規則(原料清單) => 技術棧(Objects, Numbers)
• 上層改動頻率高，下層改動頻率低，代表各層的程式碼會是建構在較穩定的基礎上（下層改動頻率低，所以較上層穩定）

分散式系統的寶貴經驗

• 切分時間線圖，時間線之間必須互相協調
• Actions 的執行並不固定，這一次花的時間不保證下一次也是如此，也不能假設有固定順序
• 即使機率很小的順序錯誤也有可能在實務發生
• 藉由時間線圖來更清楚地視覺化程序

從時間線學到的事

• 將大程序拆成小程序能讓軟體設計更加容易
• 時間線圖能告訴我們系統行為如何隨時間變化
• 時間線圖具備彈性

第二章總結

1. 以下哪項是 Action

   • 調整食品
   • 擀麵團 ✅
   • 財務數據
   • 計算採購清單

2. 分散式系統中，如果沒有對多條時間線進行協調，會導致什麼問題？為什麼？

   • 系統無法存取資料
   • 程式無法重構
   • 各個步驟的執行順序可能錯亂 ✅
   • 函數無法被重複使用

3. 分層設計的核心理念

   • 把所有邏輯集中寫在一層，方便管理
   • 將動作與資料混合處理，提高效能
   • 根據變化頻率，把程式碼拆成多層，讓上層依賴下層穩定性 ✅
   • 依照程式語言語法自動分類程式碼

---

第三章 分辨 Actions、Calculations 與 Data

Action - 會產生 Side effect，是 impure function
Calculation - 透過運算將輸入轉為輸出，Pure function
Data - 關於事件的事實紀錄

應用時機

• 以買菜為例：

  • Action - 需要特別當心，如檢查冰箱、開車到賣場、買東西
  • Calculation - 需要做決策，如列購物清單
  • Data - 需要保存，如購物清單

  會中討論：殺價是 Actions

• 重點：FP 程式設計師要注意 Action 可能是由多個 Calculation, Data 及其他 Actions 構成。要了解如何將 Actions 拆解成 Calculation, Data 及其他小 Actions

買菜教會我們的五件事

1. ACD 觀點可套用在各情境中
2. 每個 Actions 中可能藏有 Calculation, Data 及其他 Actions，關鍵就是如何將 Actions 拆解成 Calculation, Data 及其他小 Actions，但拆解也需要適可而止
3. Calculation 可能由其他小 Calculation 與 Data 組成，常見分解形式為將一個 Calculation 分成兩個小的 Calculations，並將前一個 Calculation 作為後一個的 input
4. Data 就是 Data，不會由 Calculation 或 Actions 構成
5. 流程中的 Calculations 很容易被忽視，一般來說在決策與計劃的地方就可能有 Calculations

深入探索：Data

• Data 就是關於事件的事實紀錄
• 在 JavaScript 中，Data 透過內建資料型別來實作
• Data 的意義需編碼在結構中，換言之，Data 的結構要能反映 domain 中的資訊
• 假如某個清單中的順序項目很重要，那所選的 Data 結構就要能保留順序
• 不變性
  • 寫入時複製 (copy-on-write)：更動 Data 之前先複製
  • 防禦型複製 (defensive copying)：複製需要保留的 Data
• 優點
  • 可傳遞性與可儲存性
  • 可比較異同
  • 可解釋性
• 缺點
  • 需要被解釋才有作用
  • 沒有被解釋就只是一堆位元碼
• FP 很大一部分技巧在於如何表達資料，使其當下能被解讀，未來也能重新詮釋

應用實例

Coupon Dog 為例

• CouponDog 是個優惠碼資訊站，對此類訊息感興趣的可以留下自己的 email，該平台會美洲發送優惠碼電子報給訂閱者。只要邀請 10 為好友，好友跟自己都能獲得更優惠的折扣碼。
• 流程圖
  
• 將 Plan list of emails 拆分為更小的 Calculations
  

Action 會在程式碼中擴散

• Actions 最惡名昭彰的特質是其時間依賴性會在程式中擴散
• A 為 Action，在 B 呼叫 A，B 就會變 Action
• 在 C 呼叫 B，C 也會變 Action

Actions 形式多變

• Function Calls
• Method Calls
• Constructors
• Expressions
  • Variable
  • Reading Property
  • Reading Array
• Statement
  • Assign value
  • Delete property
• 只要在程式中用到上述這些，其效果便會擴散

第三章總結

1. 哪一段屬於 Calculations ?

   • alert("Hello world!")
   • new Date()
   • selectCouponsByRank(coupons, "good") ✅
   • emailSystem.send(email)

2. 請舉出另一個日常生活中的例子來說明其中的 Action 與 Data 是什麼

   • 錢包是 Data，看錢包的錢是 Action，把錢包的錢花掉也是 Action
   • 這本書是 Data，參加讀書會是 Action

3. 請說明「 Actions 的特質會在程式中擴散」這句話的意義，以及這種特性可能帶來的風險

   • 當一個函式具有副作用（即 Action）時，其副作用不僅僅局限在這個函式內部，而會隨著程式的調用鏈一路傳播下去。換句話說，如果一個 pure 的函式（Calculation）調用了含有副作用的函式，那麼這個原本 pure 的函式也會因而變成 Action，變成一個帶有副作用的函式。而當更多的函式調用這個帶有副作用的函式時，副作用的「污染」就會逐漸擴散到整個系統中。
   • 可能帶來的風險
     • 測試與調整困難
     • 狀態同步問題
     • 程式邏輯難以理解
     • 重用性降低

4. 為什麼在函數式設計中，我們希望將「決策」與「行動」分開？

   • 可以減少記憶體使用
   • 增加程式碼長度使其更安全
   • 使程式更容易測試與重用 ✅
   • 讓函式無法被呼叫

[LoisChen68]

👍🏻