今年一月開始了我的前端工程師人生，我一直知道自己的程式能力並沒有多強，在面試前我照著線上課程完成了一個使用 vue 實作 Todo-list 的小作品，但其實我並不太懂那隻程式如何運作。
也許是運氣、也許是資工系的學歷有用，反正我覺得並不是因為程式 Demo 讓我擁有了人生第一份正式工作。但經過一些曲折離奇的故事，我在 11 月時換工作了，雖然至今也才短短一個多月但也摸到許多新技術。
以下是我對於這一年所碰到的前端技術回顧。
jQuery
2020?JQ?是的，JQ 沒死只是凋零。 在前一份工作裡，工作有 90%以上的時間是使用 JQ 完成，所以 JQ 不好嗎？只能說看需求 工作一陣子後會體悟到客戶也好、老闆也好，根本沒有人在乎你到底是用什麼技術完成需求的，因為他們要的是你完成這個需求就好。
不可否認的是，JQ 還是一個很好入門的 libary，但是以現在前端的發展趨勢來看 MVVM、資料驅動還是較為主流，直接操縱 DOM 的 JQ 顯得有那麼一點過時，且現在瀏覽器的原生 API 也不需要 JQ 來協助跨瀏覽器的相容性了。
那對於剛入門的新手還有必要學 JQ 嗎？我覺得不用，除非真的有興趣不然把時間拿去學三大框架對未來比較好。雖然我想還是有些職缺會是使用 JQ 但這些工作的薪水說真的不會太高（我有切身之痛，跳槽後的薪水真的是有很大一段的差距。）
所以即使在 2020 JQ 還有呼吸，但我想我不會再使用它了。
React
身為前端工程師學習三大前端框架是一個必須面對的選擇題，即使只會 JQ 也能找到工作，但我相信大部分的工程師都是喜歡追求新技術的人……吧？
2019 對於 React 是一個重要的一年，React Hook 的正式發佈也代表了前端即將面臨一個新時代了。 而 2020 的我開始學習 React，也在 class component 及 Hook 中感到困惑及徬徨。我該馬上追尋新技術？還是先學用戶基底尚多的 class component？最後我選擇了 Hook 因為好學ㄏ（但其實它的底層實作並不是很好理解。）
但我在第一份工作的期間接手到一個使用舊版本 React 的產品，所以我還是必須去學習 class 的寫法。兩兩比較後我更加確定 Hook 一定是趨勢。
開始自學到稍微有點概念後終究還是碰到 redux 這個一定會碰到的門檻。它真的很難理解，一開始真的無法悟透為什麼要把改變狀態這件事繞一個圈做，為什麼我需要 action、reducer 及 store 而不是一個 setter 及 getter 就好？但開始理解後會發現它其中的精妙，且對於 reducer 這個設計感到佩服（後來接觸 FP 後，就知道它原來就是利用 pure function 的概念在實作）
那到了 2020 還有必要學 class component 嗎？今年面試時或從朋友待的公司聽到如果有使用 react 的話，大部分都已經翻或正在翻成 Hook 了。
除非除非真的有維護 legacy code 的必要，不然目前我找不到理由學 class component。
Functional Programing
簡單來說 FP 就是讓「function」成為程式中的核心，而不是大家比較熟悉的 class、object 的 OOP 概念。但其實這裡的 function 比較接近數學中「函式」的定義，目標是為了讓盡量減少程式中的「side effects」，讓程式具有更高的維護性。 而 FP 裡比較重要的概念就會有 higher-order-function、pure functions、declarative programming 及 currying 及其他更難懂的東西，來幫助我們將複雜功能可以分解成一個一個小函式最後在組合起來。
最早最早認知到 FP 的存在是因為在使用 lodash 這個基本上 js 開發者都有用過的 library。我對於 lodash 中 _.chain 這個 API 感到十分訝異，這世界上居然有這種操作？一開始不知道怎麼稱呼這個東西之後才知道它就是「declarative programming」的概念。 總之我對於這種 patten 感到非常的好奇，剛好看到 lodash/fp 這個 library，所以就開始研究這個東西，但研究個一兩天才遇見這個領域的主流「Ramda」也在那時專案的小部分模組裡試用看看。
BTW lodash/fp 的 git repo 中有提到一篇文章（很值得讀）是解釋為什麼在 lodash/fp 反而沒有.chain 這個 api，一開始我也有點疑惑，但開始理解 FP 後才發現，pipe / compose 才是這個世界的真理。
「替身使者是會互相吸引的」，就在我尋找下一份工作時剛好看到一份 JD 上是寫「對於 FP 有興趣的人」及其他我還算符合的工作能力需求。就投了履歷。 也因為這段時間的研究，面試上有關 FP 的題目應該是接近全對了（但 FP 部分考的其實算簡單，畢竟是一個相對冷門的領域），但也不知道這個考試比重有多大就是了。 結局就是我獲得了這份 offer 也就是我現在的這份工作，主管也的確是非常非常崇尚 FP 的開發者（或者可以說信徒了）。
關於 FP 還有很多很多概念可以說，如果我 2021 想參加 it 邦鐵人賽也許我就會選 FP 作為主題吧。它的確改變我對於看程式的角度，也開始用一種完全不同的思維在設計程式。
graphQL
是我到現在的公司才開始使用的技術，但早在很久就聽過它的威名。 真正實務上使用它之前，我都還是對它充滿疑問（其實到現在也還是），很強很好用，但我實在不知道怎麼簡單的解釋，我的理解它就是一個「讓前端可以用更加簡單且優雅的方式取得後端的資料，而且雙方都是用類似的架構在溝通。」 在使用 Restful API 中，我們都要看後端的文件來實作 api 串接，但其實在前後分離的實務上總是會發生某一端在等另外一端的狀況，而且 API 的資料結構的設計也是直接關係到後端取資料時/前端 render 時的方便程度，所以蠻常為了資料格式做了不少「討論」。但在 graphQL 這一切就都變成了 schema 及 resolver。只要 resolver 定義好我想要哪些 field 我就取哪些，而且我只要看 schema 我就知道我可以取回哪些資料以及它們的型別，而這一切都不需要另外寫文件來溝通，這真的省下很多很多麻煩。
還記得在剛聽到這項技術剛好看到一篇文章在講「redux vs apollo(一個 graphQL 框架)」，那時我心裡想「三小？這兩個完全是不一樣的東西吧？」，一個是狀態管理框架、一個是用於 API 的解決方案。 但當我開始使用後，的確他們要解決的問題是不一樣的。但其實開始使用 apollo 後會發現「可能從一開始就不需要那麽多的 global state」現在回頭想想，那篇文章的作者是鬼吧。 當然，graphQL 還有很多功用以及實作的眉角，但自認為我對這方面真的沒有到很理解。
TypeScript
TS 應該是近兩年前端新專案環境建構時，一定會被討論到的技術。畢竟三大框架都已經可以兼容它了。 相信大部分資工系的學生都學過 java、C/C++其中之一的語言。先不論他們差異，總之他們都是強型別的靜態語言也就代表他們宣告變數時都是必須一起宣告型態且之後也不會自動轉型，但其實大家一定都有過「這樣寫好麻煩哦，看看動態語言多麼方便。」 而當開始碰到「_ is not defined」就又會開始想「難道我每次都要在 runtime 才知道我錯了嗎？」 這時候前端開發的救星 TS 就降臨到這個世界上，型別推斷、型別標注以及其他特性和工具讓前端程式有了更高的可維護性。我們可以降低很多以前在 runtime 時才會得知的低級錯誤。 雖然有人會覺得標注型別很煩，但我們公司是有用 graphQL codegen 來自動產生型別，所以已經少了很多型別要手動宣告了。
使用 TS 就真的無敵了嗎？可能是踩過的坑*還不夠多，我的使用體驗是還不錯。但同事覺得它比較像「補足 JS 的部分缺點，但大家也都知道 JS 是怎樣的語言，所以只能說還可以再加油吧。」
很重要但較少碰到的
前端打包工具：實在沒有什麼基礎建設的經驗及機會，只能說這部分還很生疏。唯一的經驗就是將前公司的某個是使用 JQ 的舊專案的 webpack 升到 v4 然後改為可以支援 react。但還是沒有碰到太多的優化打包大小及速度的經驗。但我覺得這些是 webpack 的精髓之一。
Unit test：真正開始在實務上碰到 Unit test 是在現在的公司，雖然之前有稍微看過，但在前公司時開發時程比較趕，所以其實在專案中根本沒有任何 Unit test 的程式。 前端到底需不需要（適不適合）測試？其實現在已經有些插件能讓 Unit test 測試 DOM 的狀態，再加上公司目前的 codebase 比較偏向 FP 寫法的 code 所以做測試其實也還是相對容易。但目前我們團隊也沒有特別追求前端的測試覆蓋率就是了。
在 2020 最後的最後
稍微回顧一下比較不是那麼技術的事情。 在第一間公司時，讓我體會到真正的實務上程式設計。而在 11 月時我換了工作，至今為止覺得十分舒適但又有跳戰性。短短一個多月我學習到很多，感覺我更「知道了自己不知道什麼」。
我真的很感謝同事很盡責的 code review 及很認真的跟我講解一些框架或函式庫底層實作的概念。特別是 code review，在以前程式可以動就好而現在會被指出程式碼中不夠完美的地方。雖然一開始真的有點失落，但這部分真的幫助我很多，也讓自己知道還離資深工程師差得有多遠。
2021？
有在關注前端趨勢的人應該都會知道，WASM 及 FP 都是近幾年的 buzzword，React hook 及 Vue 3.0 都開始往 FP 靠攏了，我對於 FP 在前端的發展還是相當有信心的。
雖然 WASM 目前在產品的應用上也還沒到非常普及，而且現在在工作上的問題也不太需要用 WASM 來做效能優化，而且本來的 codebase 也沒有用到什麼靜態語言所以也不太可能復用來做 WASM。雖然是這樣說但我還是認為 WASM 在未來還是在前端會佔有一席之地。
為此我主要會把時間投資在 Rust 上，畢竟它是有支援 FP 且適合編譯成 WASM，也是我們團隊最近有討論到語言。
再來就是 flutter 及 Haskell，flutter 是因為我們團隊有一部分的產品是用 flutter 實現，而且也完全沒接觸過 hybrid app 感覺是可以嘗試看看的領域，Haskell 的話單純就只是為了理解 FP，畢竟它要拿來應用真的太難了。
雖然聽起來很多，但是應該也只是玩玩看而已，畢竟在前端技術迭代都非常的快，也許光是 2021 的前端新技術我就追不完了。
附註*這篇文開始撰寫後幾天，我就遇上 TS 版本的問題。情境大概是第三方套件的.d.ts 檔一直出 error，而 tsconfig 也確定路徑沒有包含 node_modules 及有打開 skipLibCheck
附註** 雖然是這麼說但是其實就算不懂 FP 也是有辦法使用 Hook 來撰寫程式， Vue 的 composition api 我就不太確定了，但我想就應用上應該是就算不用了解 FP 也可以使用。