這是第二次參與鐵人賽，還是很感動終於完成!
先來回顧一下此次系列文包含的主題：
這系列文主要想環繞 《簡約的軟體開發思維：用 Functional Programming 重構程式 - 以 Javascript 為例》和《mostly-adequate-guide》兩本書的內容來撰寫，但寫到後面發現兩者有點難以結合，前者更實務好懂、以重構角度出發，後者更專注於 FP 概念與理論，所以這系列文後半部會更聚焦 《mostly-adequate-guide》 裡面的內容，雖然沒有完全涵蓋，可能也有不夠深入處，但想說至少可以先簡要介紹，作為入門系列，帶大家初步認識這些 FP 工具和設計原則。
如上所說，這次的主題是圍繞兩本書來撰寫文章，但在 30 天內要分享兩本書的全部內容其實非常困難，難免有取捨的地方，因為時間有限，有些原本規劃要寫的、我覺得值得介紹的主題這次沒寫出來，例如：
時間線圖的概念是《簡約的軟體開發思維：用 Functional Programming 重構程式 - 以 Javascript 為例》書中所提到的，透過繪製程式的時間線圖，我們可更理解程式中事件發生的先後順序，這對於除錯程式碼非常有用，可清楚知道各種時間線上的狀況，理解 race condition 問題、以及如何解決，如何強制某事件發生於另一事件之後。
乍看之下可能覺得時間線圖和 FP 沒有太多關連，但其實時間線圖是 Functional Programming 管理共用狀態與程式複雜度的一種方式，它讓我們能藉此看到程式中的依賴關係，並進一步思考如何協調時間線，讓共享狀態更安全、可預測。
且時間線圖我覺得對於實際開發蠻實用的，如果遇到程式結果不如預期，可以試著繪製時間線圖來釐清，可惜因篇幅關係沒有介紹到～有興趣的推薦閱讀之前讀書會夥伴的文章 Functional Programming 共享資源、協調時間線 筆記！
自然轉換是《mostly-adequate-guide》在後面章節介紹的內容，算是 Functor、Monad 篇章後的進一步延伸，不過要深入研究和撰寫又需要花點時間和篇章，因為想留一些篇幅給實務一點的應用，因此捨棄了這部分的介紹，但我覺得理解這個會對 FP 的世界有更完整的認識，如果有興趣的，可參考閱讀這屆鐵人賽 olddunk 大大寫的Day 18. 自然轉換 - Natural Transformation和Day 23. 時空穿越 - Traverse & Sequence。
有機會自己也想補一下這部分內容，希望能再寫文章來分享這塊！
因為《簡約的軟體開發思維：用 Functional Programming 重構程式 - 以 Javascript 為例》書中大部分以實際程式碼的重構來解說，原本想參考這方式，找個簡單應用範例程式，然後將它重構為 FP 的寫法，但後來發現要找適合的應用範例有點困難，雖然有 AI 後要產出範例程式應該不難，但又覺得要花篇幅介紹程式內容與邏輯，同時又擔心應用太小、複雜度不夠，無法看出重構為 FP 帶來的優點，於是只好先捨棄這主題，可能要預留足夠多篇幅才能好好介紹與重構～
在砍掉重練！？學習Functional Programming兩個月的過程、心得影片中，作者有提到，用 JavaScript 學 Functional Programming 會讓人有繞一圈的感覺，因為 JavaScript 不是純函數式語言，讓我們必須先用程式實作出純函數式語言下的資料結構如 Functor、Monad 等，我們要一邊看如何實作出相同結構，又要一邊看這結構下的 FP 特性，導致學習上更困難，也容易失去焦點，因此作者會更建議去學一個純函數式的語言，例如 Haskell，如此才能體會 FP 真正的精神。
我在寫這系列文時本來沒想到要挖這麼深，為了要將文章寫清楚，才去讀了相關網路資源，也才看到很多人推薦去學 Haskell，我想我的 Functional Programming 學習之旅下一步，就是去學習一門純函數式語言，以真正感受 FP 的威力。
以下列出如果對 FP 有更多興趣，推薦進一步閱讀的參考資源，這也是我的待讀清單：
不過如果想先以自己熟悉的 JavaScript 來學習 FP 的話，我覺得作為入門也是可以的，若過程中覺得理解 Functor、Monad 這些概念很痛苦，不知道在學數學還是學程式設計，非常推薦參考 FizzyElt 大大在 重新思考 FP 的分享，為 FP 的學習提供具體的脈絡，並提出看待 Functor、Monad 這些概念的觀點，我們應該要思考，當下這情境要利用 Functor、Monad 的這些特性達成什麼效果，以避免過度糾結於 Functor 應該是什麼，Monad 應該是什麼。
順帶補充，我一開始發現 FP 深入下去就會有一堆數學的東西，也覺得很害怕，因為本身數學不好XD，想說哇又要學程式、又要學數學，怎麽辦得到，而且數學又非常抽象，很多時候都只能靠比喻或舉例來理解，但比喻又不一定代表全部...，後來想想先多看看再說吧，總是能歸納出自己的理解，即使是透過舉例來理解我覺得也無所謂～大家都是從具體的東西開始學習，才有辦法抽象到更高層次（我也還沒到那個高層次><）。
另外，基本上 FizzyElt 大大對於 FP 的說明我都非常推薦！講得非常清楚好懂，收穫很多！
因為去年寫了設計模式的鐵人賽主題，之前面試有被問過：「你實務開發上最常用哪個模式？」，當下愣了一下，因為太難明確說出來了 XD
我覺得 Functional Programming 和設計模式的概念很像，學習 FP 是多了一種看待程式設計的角度，並不是為了要在開發時說「這裡我要用 Functional Programming 的寫法」或是要說「我很懂 Functional Programming」，我覺得這些都是自然而然的融會貫通到開發上的，很難明確解釋或辨別，事實上我覺得也不太需要明確辨別。
前陣子參加 Huli 大大的《JavaScript 重修就好》新書導讀會，在 QA 環節有人問 Huli 說為什麼之前寫 React 現在換到 Vue，當時 Huli 說他現在什麼都寫，重點是能解決問題，他把自己定位為能解決問題的人，這段讓我印象蠻深刻的，在去年的[Day 30] 系列文總結與完賽心得也有提到：「重點不是設計模式，是你要解決什麼需求才是最終的方向。」，我覺得一樣可以套用到 Functional Programming 上，「重點不是 Functional Programming，是你要解決什麼需求才是最終的方向。」
對軟體工程師來說，不管是什麼新技術、工具、設計模式、FP 又或是 OOP，重點是它能否解決當下的問題，要清楚知道它能解決、適合解決什麼問題，它不能解決、不適合解決什麼問題，還有它能帶來哪些優缺點。
認識 FP 後，我覺得我學會了看待問題的另種角度，學會如何分解和重組問題，如何將片段的小功能完成後，再組合、堆疊成大的功能與元件，不過這仍然需要持續練習、在開發中逐漸累積經驗，就在未來繼續努力囉～
今年參加 2024 鐵人賽頒獎典禮時，聽到雷N大大連續 6 年參加鐵人賽（加上今年是第 7 年），當下超佩服，覺得連續參賽的毅力比得冠軍更不容易，當時就想說我也想試試看多參賽幾屆，於是今年就報名了～
這次參賽前沒有像去年太多糾結，也有先讀了一些相關書籍，雖然過程中還是很痛苦，因為發現 FP 水很深，要深入介紹的話，相關讀物根本讀不完...，再加上這次不像介紹設計模式一樣有特定撰寫格式可以依循，要自己規劃文章敘述脈絡，很苦惱該如何規劃才能清楚說明主題。後來是參考了 Huli 大大在跟著小明一起搞懂技術名詞：MVC、SPA 與 SSR文章最後提到的方式來介紹：
我們可以用三個問題來幫助自己理解一項事物：
- 為什麼要有 XXX？
- 沒有 XXX 跟有 XXX 的區別是什麼？
- 所以 XXX 是什麼？
不確定是否適合用來介紹 FP 的主題，但有個特定的脈絡我會比較好規劃文章，所以後面蠻多篇文章可以很明顯看出我都依循這幾個要點來寫文章，希望還算好理解～
雖然參賽過程很辛苦，這中間又有忙很多其他事情，但還是很努力完成了，發現去年的[Day 30] 系列文總結與完賽心得雞湯到今年還是非常適用，所以再次列下來鼓勵自己！
雖然對 FP 那些深入的數學理論不算很理解，但先寫寫看就對了～可以在之後繼續調整。
歷屆鐵人賽其實有蠻多 FP 的主題，一開始也會擔心自己寫的內容不如別人，或是主題重複，但是回到參賽目標，我只是想讀完 《簡約的軟體開發思維：用 Functional Programming 重構程式 - 以 Javascript 為例》和《mostly-adequate-guide》這兩本書，而實際上我也順利讀完了，有達到目標就很棒了~
雖然我現在還是沒有很厲害，但相信自己每天一點點的學習都是累積，至少跟去年的自己相比，我又多了解了 Functional Programming 一點點了！
FP 是我去年就蠻有興趣了解的主題，雖然不是什麼具體可以寫進履歷的技術，可能也無法直接看出在工作上的效益，也許有其他技術是 CP 值更高、更值得學習的，但就像龍哥說的，學習是為了自己，只有自己覺得有幫助或自己有興趣，才能走得長遠。而因為我對 FP 很有興趣了解，所以並不後悔選了這主題~了解這些非常有趣，學到的也是屬於自己的成長。
其他雞湯們就不重複啦，有興趣可以點回去之前的文章看，這裡想再補充新的雞湯（？
馬男波傑克不是一部正向積極的劇，但我很喜歡🤣最近打算二刷，其中第二季結尾有句台詞：「It gets easier. Every day it gets a little easier. But you gotta do it every day —that’s the hard part. But it does get easier」，最近很喜歡這句，簡單來說就是累積的力量吧！每天累積一點點的努力，會越來越好的💪
為了寫系列文，我學到很多書中沒深入提及的知識，例如：型別簽章、Point Free、generator function，還有用集合來思考型別，用集合來思考 type 讓我在看待 TypeScript 時有更透徹的觀點，比較知道為什麼有 TS error（因為不符合集合的規定），剛好前陣子面試時，也有面試官提到說可以用集合的概念來思考 TypeScript。另外也藉這機會再多了解了一點 RxJS，真是越看越覺得這套件的設計哲學十分迷人，很開心能藉此機會又學到更多。
也非常感謝網路上許多大大的分享，PJ 和 FizzyElt 大大的文章真的幫助很多，FizzyElt 大大提供幫助很多的學習資源，FP 相關的筆記都能淺顯易懂的說明，非常佩服！
然後為什麼我每次想學什麼東西都會發現 PJ 大大都寫好了，好強...🥹
另外補充，這次也自己畫了很多示意圖，因為 FP 有很多抽象的概念，很適合用示意圖來說明，所以這次也畫圖畫得很開心！這次應該幾乎每篇文章都有至少一張示意圖了，我想我應該是蠻喜歡用示意圖來學習和解釋概念的，對我來說，也許圖像化是另一種語言，程式語言是種語言、人與人溝通的自然語言是種語言，圖像化也是種語言，當我能用不同的語言來表達相同訊息時，代表我對這概念的理解更透徹，另一方面，也希望透過圖示來讓整體文章不那麼無聊，希望大家喜歡~
最後的最後，給自己還有參賽的大家大大的掌聲吧！堅持 30 天真的不容易~
如果你喜歡我的系列文，可以多多分享，文章中有任何敘述不清或錯誤的地方，都歡迎指教與討論！
若有興趣，也可以追蹤我的 Medium，在我還沒建立好個人部落格前，會先繼續在 Medium 更新學習筆記～
希望這次 Functional Programming 之旅還算充實，謝謝大家，我們下次見👋🏻
辛苦了! 來恭喜一下~
是說在所有的 haskell 書裡，如果只推薦一本，我會推 https://haskellbook.com/
雖然有點貴但絕對值回票價 XD
感謝大大!
立刻補進待讀書單內!(剛剛看書中章節介紹，確實蠻紮實的哈哈...
iThome鐵人賽
看影片追技術