新工作#

去年年底我到了目前任職的公司，相較於上一份工作這裡的節奏明顯快了很多。

雖然都是開發網頁前端但剛好遇到某些專案運行的載體較為特殊，所以在 bundle size 或者效能優化上比起一般 web app 更為要求，這些都是我在之前前端開發經驗裡完全沒遇到的挑戰。

除此之外還是有 dashboard 這種較為常見的專案，但也因為這裡的關係遇到許多之前沒見過的課題，例如大型表單中各個元件/欄位的拆分、復用。

新產品的開發#

在這幾個月主要在開發一個新產品所以就有機會從零建設一個前端專案，雖然還是會參考舊有專案，但也剛好讓我開始想為什麼有些部分當初是選用這個套件/寫法/架構的。

在這之前其實我沒特別關注前端工程化、基礎建設等其他跟非功能開發的議題，畢竟之前都有人先寫好了 xD。

但也發現自己在挑選 package、library、framwork 時其實都是參考我的開發癖好但真實狀況是要考慮到許多事情，像是團隊的開發習慣、考量其他人對於這個技術的了解程度或者上手門檻，一想到這些事情其實我大部分時候都會依循現有寫法繼續實作。

像是 utils 可能就是直接用 lodash 但其實我個人更偏好 ramda，mui v5 的 theming 就會繼續使用 makeStyles，但我更喜歡 styled component 的寫法。 等等之類有關開發風格的事情，不論使用哪個方案其實都能完成需求但就是要考量到團隊的共識。

但還是有成功導入一些新工具：graphQL codegen ，它可以根據 gql schema 自動產生 ts type 或甚至是 hook（看設定），這個工具最早是在前公司裡接觸到的，用過之後就覺得太香了，這個開發體驗真的提升不只一個檔次。

在「大部分」情況下不必為了這個 query/mutation 多寫一個 ts type，甚至是可以不寫 validator 的情況下就可以讓 ts 去推斷 response 就是這個 type （ok ，我知道這不一定保障後端回傳一定是對的 type） 否則我們通常會用一些工具（通常我們是用 ajv）然後利用 type guard 讓 ts 能夠推斷這個變數在通過 validator 後一定會是這個 type，所以除了要寫這個 query 的 type 還要另外寫這個 query 的 validation schema

而使用了 graphQL codegen 後上述情景都可以省略掉，這真的省下不少開發時間。

參與面試#

今年也是我第一次面試別人，雖然說是團體面試但老實說可能還比自己在面試工作還緊張，還是會有一點怕說錯什麼話讓面試者或同事對於我的能力有所質疑或可能對於這次面試的體驗不好。

在這幾次面試的過程中，不斷思考著「到底什麼樣的人才適合我們團隊。」但面臨幾次其實這個面試者跟我們互動起來很不錯但就是能力稍嫌不足，也開始發現堅守一開始訂下的選人標準是蠻困難的。

經過幾次動態調整以及反思的結論是：很多時候在能力或者個性沒有特別的問題時，其實只要有「感覺跟這個人 co-work 會不錯」、「有潛力的」、「自學的熱忱足夠」等等類似的特質，就會覺得這個面試者是可以再往後面的關卡前進。

技術#

前一陣子 react 18 release 了，其中 concurrent mode 相關的 feature 應該是最令人期待的部分，只是剛好目前我們的專案沒有場合需要用到這些 feature，但看起來確實蠻令人興奮的，可以看出來 react 在 UX 上給出了一些不錯的解決方案。

今年上半年花比較多時間可能是 svelte 了，但就是純粹出於好玩才去學習的。雖然有評估過是不是要在一個規模極小的專案改用 svelte 玩看看。

以那個專案來說客觀條件上算是蠻適合的，因為他剛好「講求 bundle size」、「一個簡單的小頁面但又需要一些互動」以及「原本只用 vanilla 開發」，所以如果真的要遷移到 svelte 幾乎沒有困難而且之後會更好維護及開發。

但考量到如果之後不是我主要維護這個專案那是不是就要開天窗了，所以也只能想想而已。

下半年#

除了工作上常用到的 react 以及 graphQL，在其他方面會放比較多心力在 svelte 上，雖然工作上沒用到但我還是蠻喜歡這個框架的。

然後多看看有關前端工程化、測試以及 CI/CD 等等與功能開發較無關係的知識，最近愈來愈覺得這方面的知識真的蠻重要的，特別是這陣子在開發新專案時。