Grokking Simplicity FP CH4 ~ CH5

[Yo0GuitarIT]

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

筆記章節

1. Ch4 - 擷取 Action 函式中的 Calculations
2. Ch5 - 改良 Actions 的設計

筆記資訊

• 日期：2025/04/17 @Tech-Book-Community
• 導讀人：Steven
• 筆記工：Yo0
• Slider Here

回顧

Side Effect（副作用）

• 函數除了回傳值，還改變外部狀態（例如：寫入資料庫、取得當前時間）

Actions（有副作用）

• 執行結果每次可能不同
• 例子：
  • sendEmail()
  • saveUserDB()
  • getCurrentTime()

Calculations（純函數）

• 輸入相同 → 輸出永遠相同
• 例子：
  • sum([1,2,3])
  • string_length("hello")

Data（資料）

• 描述事實、無副作用
• 例子：
  • { "name": "Eric" }
  • [1, 2, 3]

核心觀念

• 程式設計應傾向：Data > Calculations > Actions
• 將 Actions 拆成 Calculations + Data → 提高可預測性

Ch4：抽離 Action 中的 Calculation

常見觀念 Q&A

Q1. 程式碼越多是好事嗎？

• ✅ 函式拆分會增加行數，但提升重用性、可測試性、可讀性

Q2. FP 僅關心重用和測試？

• ❌ 不只如此！還涵蓋 並發、架構、資料建模 等重要面向

Q3. 抽出來的計算能獨立使用重要嗎？

• ✅ 重要！拆小能提升重用、測試、理解

Q4. FP 強調不可變，為何仍會修改變數？

• ✅ 不可變是指創建後不可變
• 初始化時允許改變，但創建後不應再變動

抽離 Calculation 的步驟

1. 抽出純計算邏輯
2. 辨認隱式輸入/輸出（例如全域變數）
3. 將輸入變成參數
4. 將輸出變成回傳值

Note：參數與回傳值皆應保持不可變

概念總結

1. Action 含隱式輸入/輸出
2. Calculation 無隱式輸入/輸出
3. 全域變數為常見隱式依賴
4. 用參數傳入 → 去除隱式輸入
5. 用回傳值 → 去除隱式輸出
6. FP 設計傾向將 Action 拆成 Calculation

Ch5：改良 Actions 的設計

常見觀念 Q&A

Q1. 為什麼程式碼越寫越多？

• 雖然行數增加，但單一函式更小、更易理解與維護

Q2. 每次複製購物車陣列不會效能差？

• 複製確實較耗效能，但 現代垃圾回收處理很好
• 不可變設計能換來更好的預測性與穩定性

原則：最小化隱式輸入與輸出

• 隱式輸入：非參數的依賴（如全域變數）
• 隱式輸出：非回傳值的影響（如修改全域）

✅ 消除隱式 → 增加模組化、可重用性、可測試性

---

設計原則：拆解就是力量

函式的拆解優勢：

1. 更易重用
2. 更易維護
3. 更易測試

再小的函式也值得拆解，只要能提升可讀性與邏輯分離

Calculation 函式分類（有助後續分層）

分類代號	類型	說明
C	Cart	購物車操作
I	Item	單一商品相關操作
B	Business	業務規則（如免運門檻）
A	Array Tool	陣列處理工具

✅ 業務規則應獨立於資料結構，避免相依造成日後維護困難

---

小結

1. 使用參數與回傳值取代所有隱式依賴
2. 將函式職責拆到最小，提升組織與邏輯一致性
3. 現在的 Action 不再需要了解底層資料結構

📌 越多純函式（Calculation）與接口函式，程式就越穩定

Q&A

1. 純函式、副作用與可測試性

• 「容易有副作用」：若 function 沒有顯式輸入輸出，容易埋藏副作用。
• 為了好測試才拆 function，但也可能會增加預期難度與閱讀負擔。
• 單一職責 function 更好測試，但閱讀上可能要來回跳轉。
• 適當抽離可重用邏輯，否則寫 100 次不如抽出來。

---

2. 關於 Function 拆解

• 小 function 容易 unit test。
• 使用 JSDoc 時，文件容易過長。
• 認真寫好 TypeScript，可以輔助理解。
• Colocate function（邏輯靠近使用處）有助可讀性。
• 結論：依據專案需求、維護性與可讀性斟酌拆解粒度。

---

3. FP（Functional Programming）與 OOP（Object-Oriented Programming）的比較

Functional Programming（FP）：

• 更適合資料轉換、邏輯純粹、stateless 的場景。
• 高可測試性、純函數、無副作用。
• 適合短期、小工具程式。
• 例如：addToCart(item)、calculateTax(rate)。
• React 的設計核心也傾向 FP。

Object-Oriented Programming（OOP）：

• 適合有共享狀態、角色權限、UI 元件、遊戲邏輯等情境。
• 更適合複雜系統與長期維護、需要設計模式。
• 例如：Cart.add()。
• Kotlin vs Java 差異：Kotlin 更 FP 風格。

🌟 混合式架構：

• 實務中多為混合使用，根據情境決定。
• 不見得要完全 FP 或 OOP。
• 團隊風格與語言習慣也會影響選擇。

---

4. 常見困擾與現場經驗

命名與可讀性：

• 命名不好會讓 FP function 很難理解。
• 高階函式過度嵌套會讓回傳值難以追蹤。
• Fn 包 Fn + pipe 很容易讓接手人迷失。

維護與可讀性挑戰：

• function 拆太細 → 需要來回閱讀多個檔案。
• 有時 function 雖命名合理，但因資料流不明仍不易理解。
• 單一函式包過多邏輯（e.g. handleSave() 裡面塞一堆條件）也是常見問題。

---

🔍 延伸閱讀與資源

• 為什麼要學 Functional Programming？@ iThome

---

🤔 討論總結

主題	FP	OOP
適用場景	純邏輯、資料處理、小工具、無狀態流程	共享狀態、角色權限、長期維護、大型專案
優點	可測試性高、可預測、簡潔	擴充性好、結構明確、利於團隊合作
缺點	可讀性差（函數過多、命名不好時）	初期架構成本高、學習曲線較陡

---

💬 金句摘錄

「過早的最佳化是萬惡之源」
「React 寫多了覺得 Java 很難懂」
「FP 寫到極致會讓人心智負擔加重」
「選擇 FP 或 OOP 是 Lead 的課題，打工仔就好好寫 code」
「有錢誰就是老大」
「命名好不好，決定你是不是想綁標」

[LoisChen68]

👍🏻