新產品#

今年負責了一個大型前端產品的開發，我們面對到許多沒有碰過的議題，像是讓使用者自由設定 layout 的 dashboard、複雜的 map 互動，在前端的 bitwise 操作。

除了網站本身的開發以外因為商業上的需求不斷的擴張，也迫使我們在開發時必須更加注意未來的彈性以及可維護性，所以今年上半年開始認真地研究 monorepo 以及其他 infra 工具，也為了更好復用程式碼也開始做了內部的 component library、utility library。

在建立 component library 時也摸到了 rollup 以及 storybook，剛好有機會可以比較深入地認識了一些常用的工具到底幫了我們什麼，像是 webpack 實際上到底做了哪些事情、tsc 與 babel 在編譯 ts 時到底差在哪之類之類的。雖然最後並沒有全部用上那陣子研究的東西但對於整個大前端有了更深更廣的認識。

建立前端團隊#

因為組織調整的因素，我所在的 team 在今年上半年只剩我下一個前端（當然還是有其他 team 的前端幫我 code review 或討論事情），所以今年也花了很多很多很多時間在面試前端。

非常感謝主管在這方面給了我相當大程度的決定權，在選人的條件或者偏好上基本上都不會過問太多。

從六月開始我們開始積極地招募前端工程師，但其實在這段時間我們的標準是不斷動態調整，所以也因此錯過了某些可能很有潛力的人選或許他們再晚一點就有機會通過面試了。

但基本上調整的標準也是只有技術或者工作經驗等偏向硬實力的部分，但我們對於軟實力上的標準倒是沒有退讓過，特別像是團隊合作、自學能力、好奇心等等對於工程師而言相當重要的特質。

發 offer 後就變成煩惱之後帶人的問題。坦白說我一直都不認為自己是一個厲害的工程師，所以在指導或者給予協助這類的事情我總覺得自己好像做得不夠好，也因為上半年大多數前端功能都是我一個人完成導致在文件及規範上並沒有太多著墨。

但我還是直到新人報到後才真正開始面對這個問題，幸好同事們會主動把我講過一些只存在在我腦中的規範及流程寫成文件，讓我在這方面省下許多時間。

直到現在也算是快建立完這個前端團隊了，經過一陣子的合作我覺得我們之前面試對於某些價值沒有選擇退讓，是一個非常正確的決定。

當然我知道「技術強」跟「善於團隊合作」不是互斥的概念，只是大多數情況我會選擇「雖然技術差了一點點但感覺跟我們合得來」而不是會選擇「雖然技術強了一點但感覺可能會不太適合」，幸運的是我們也有面試到兩方面都是相當不錯的同事。

關於技術#

今年扣除前端以外就是花比較多時間在 Rust 上，雖然並沒有真正拿來開發什麼東西，但至少把玩起來算是一個很棒的語言，期待有一天真的能在產品上使用到它來開發。

而在前端領域今年大部分時間都是在看非功能開發的知識，像是打包工具、測試、storybook 之類的東西，但還是有將一個之前一直都還算有興趣的狀態管理 library − Jotai 導入到專案裡。

會開始使用 Jotai 主要的原因是我們團隊對於 redux pattern 感到十分的厭倦
(雖然我自己是蠻喜歡 redux 的設計以及它的生態系)
我們團隊這一兩年主要的開發專案都從 react-redux 轉而使用 context 加 useReducer 來實作 global state，雖然當初設計時我還沒加入，但我推測是以當時的時空背景的確是沒什麼太複雜 global state 需要管理，所以的確 context 就足夠我們使用。

目前 Jotai 使用起來的體驗相當不錯，光是不用寫太多 boilerplate 就已經足夠吸引我們使用了，而且 Jotai 所提供的 api 相當直覺、derived atom 這個非常強大的功能以及官方提供的各種插件像是與 reducer 結合的、用於 data persist 之類的。

也在今年下半年成功地將單元測試、元件測試及 storybook 放到現在的專案中，然後還莫名其妙地建立一個屬於我們前端 team 自己的文件網站，主要是因為寫了一陣子文件後發現 confluence 實在不是很適合我們，當初也只是因為我們是使用 jira 做為專案管理的工具才會順便去使用它。

我們希望文件每次的撰寫我們希望是有其他前端 review 後才成為一份正式的文件，但 confluence publish 後就直接是一個頁面了，雖然 draft 似乎可以共編（沒試過）但在留 comment 上我覺得輸 github pr review 的體驗一大截。以及我們有這些需求：根據標題自動產生的大綱目錄、好用的 code block 以及站內導航，所以後來還是打算自己來架設網站。

目前是使用 docusaurus 這個 SSG 框架來架設這個文件網站，它提供了許多開箱即用的組件、樣式、設定。按照我們目前的需求是可以不用太多花額外的心力去處理文件撰寫以外的事情，就可以擁有一個蠻好看的文件網站。

變全端#

在一兩個月前主管問我有沒有興趣做一些後端的 task，我對於成為全端並沒有特別想要或不要，但稍微考慮一下後決定還是開始往後端發展了。

我很常跟周遭的人說「你終究會變成全端的，為何不現在就變。」但其實我覺得這是我自己對於前端職涯的焦慮—「不知道更深入該學什麼或者能學什麼」

雖然研究其他工作上不會用到的新知識是有趣的，而且我也相信未來的某一天一定會幫上忙，只是聚焦於當下的話總會覺得看了那麼多東西但感覺對於現在的生活沒有什麼影響，總是有種令人失望的感覺。

總而言之考量到職涯發展以及保持工作上的熱情，我接受了主管的這個提議，或許接受一些不同領域的刺激後再回頭來看自己時可以更清楚地知道，對我來說什麼才是真正喜歡的，又或許我本來就是一個對於各類事情都只有三分鐘樂度的人吧？

2023?#

這一年讓我發現自己對於前端環境的知識還是不夠熟悉，所以接下來的目標可能是去研究前端工程中各個工具的原理，其他前端領域的部分，我近期比較感興趣的就是 svelte 以及 tailwind css。

我一直對於 svelte 簡潔（或者該說黑魔法）的語法感到又愛又恨，喜歡的點是簡單的就可以實現一個互動頁面，討厭的點是跟原生 JS 語法有一段距離。但我覺得如果不是工作中同時需要寫到兩個框架我想這個 mindset 切換應該不會太困難。雖然最近有一個後起之秀 solid.js 比起 svelte 他更貼近 react 的寫法 ，但整個社群或生態系感覺還是 svelte 更為健全。

至於 tailwind css，雖然大概在兩年多前就聽過這個框架，但也到這一年才頻繁出現在社群中。其實我並沒有特寫喜歡這種 utility first 的寫法相較起來我可能會更喜歡 css-in-js，但既然是現今社群推崇或者佔有一席之地的寫法我覺得都有學習的價值。且在考慮 bundle size 的情況下 tailwind 是比 css-in-js（ 先不考慮 zero-runtime css-in-js）好上一點。

只是按照目前的工作上的習慣我覺得很難在主要產品上使用 tailwind ，畢竟目前我們主要還是都用 MUI 做為 ui library，雖然也不是說不能兩個一起用但以目前的狀況來說的確是沒必要使用 tailwind。

然後多學習一些後端的知識，畢竟現在也勉勉強強算是一個 full stake 了，目前感覺自己對於資料庫操作以及設計資料結構的能力是非常的爛。

最後就是繼續學習從 2021 講到現在的 Rust，雖然直到現在沒有拿來開發過任何有實際功用的程式，但最近遇到了某些問題「也許」Rust 可以更好的解決這件事情，讓我開始評估在公司產品使用 Rust 撰寫 WASM 這件事情到底是不是可行的。

總而言之希望自己 2023 不要產生知識焦慮想要把所有資訊都接收，也不要安於現狀想說目前已會的技術直到三五年後依然保值。只要自己能夠按照自己的步調慢慢進步就好。