任務分配#

除了自己的工作要做以外，現在也要幫主管想一下哪個專案或功能適合讓哪個前端同事去處理，我覺得除了適不適合以外，另外一個我在意的點是「可以讓那個同事學到什麼？」

有一陣子我傾向把跟雲服務、infra 相關的單子指派給比較資淺的同事去接，畢竟就我自己的經驗來說在一個已經把產品做出來的團隊裡平常真的不太需要讓前端工程師去處理這些事情，即使有也會讓較資深的工程師去處理。

但剛好有這些機會讓這些同事去碰碰看我覺得是相當不錯的機會，因為即使內部文件再怎麼詳細（但實際上確實也不夠詳細 XD）我發現對於很多新人來說一個產品如何部署、如何被外部存取、如何打包等等跟功能開發有點距離的事情，可能還是不太熟悉。

當然這麼做也是會有點風險的，就是我可能需要比平常花更多心力去關心這些單子的進展如何，但我覺得這就是一種投資吧，讓某些能力或者知識不會侷限在特定一兩人身上。

與組員的互動#

過一年回頭看我覺得與組員的關係改變大概如何預期那樣，因為現在需要幫他們打考績所以我自己說話變得異常小心，深怕他們會覺得我可能會在打考績時會留下負面的評價。

但也因此搞得我在 code review 或者給於他們回饋時會變得異常彆扭，會需要拐好幾個彎告訴他們「我覺得這樣做不好」，但其實也不會影響到他們的考績。

有時候我覺得是我自己想太多，但這種事情我覺得可能寧可麻煩也不想讓他們覺得我是一個會亂打考績的主管吧？又或許我可能是高敏感人 XD

導入 Svelte 後的感想#

在 2024 的回顧中提到了有一個新產品使用了 Svelte ，目前為止我自己的評價是「好爽，如果可以拜託讓我把所有專案都重寫」，因為 Svelte 的特性使然所以當需要用到一些直接在 DOM 上操作的 library 時這一切操作都變得相當自然，而如果是 React 通常會需要別人來開發對應的套件才會比較好開發，以及 Svelte 5 後的 reactivity 設計真的太舒服了可以讓我們簡單地寫出更高效能的網頁。

當然這一切不是沒有缺點的，我覺得對於 React 開發者來說最大的門檻應該是各種 template 語法及 directive 吧，方便歸方便但是真的是造成了額外的心智負擔。以及沒有了 React 生態系裡各種 library， 這也是為什麼我們沒有考慮過重寫舊有 React 產品的最大原因，畢竟我們的產品可以說是建立在 MUI 以及 react hook form 上 XD，如果這一切要重寫真的是一個大工程。

除了功能開發#

這個產品除了程式碼的問題以外架構其實也是有許多的坑，所以我也因此被迫學習了許多系統設計的知識，除了認識到各種常見的元件和 AWS 服務，也讓我真正去思考「雖然這樣能動，但如果之後要擴展時那又該怎麼辦？」、「如果這個東西依賴外部服務，那發生錯誤時我們能夠怎麼處理」等等問題，這才讓我見識到後端開發到底有多麽複雜。

don’t go#

這個產品除了雲端架構的調整以外我們也決定重寫一個後端服務來逐步淘汰舊有的服務，既然有了這個機會重寫，我們也認真考慮了一下要不要繼續使用 TypeScript 來開發，經過各種考量以及團隊共識我們最後選了 Go。

但我自己最想要的是 Koltin 啦哈哈。

經過這半年多的使用我覺得它並沒有社群上說的那麼不堪，我自己的想法是它讓整個團隊的程式碼品質有了一個還不錯的下限，因為它的語法實在是很少所以很多功能的實現就大概只有那幾種寫法，所以誰來寫看起來都差不多了。

但也因為 Go 本身太精簡導致很多東西都要自己實作，再加上那個令人心煩的錯誤處理以及沒有 Enum 和 union type 這些好用的語法，讓我真的無法喜歡上這個語言。

雖然說還是能在 Go 能用 string type 來模擬 Enum 以及用 interface 來模擬 union type 但終究還是離其他語言差了一大步，特別是前者在 switch case 中完全沒有用，後者寫起來很麻煩且依然沒有 exhaustiveness checking 。

雖然說 lint 可以彌補上述的一些問題，但我覺得如果語言本身就有考慮到這點的話就更棒了。

在這篇文章在撰寫時剛好有了關於 sun type 的提案，希望未來 Go 能夠加強這一方面的設計吧

所以我對他的評價是，寫起來還可以讀起來也還可以，雖然不喜歡但確實是一個可以讓大多數人快速寫出一定品質的語言。

避免知識焦慮#

今年對我來說算是一個相對「鬆弛」的一年，不管是在工作上或者私人生活上，去年的我在下班後還是會花不少時間自學及追逐各種新知，總覺得快被知識焦慮壓垮的感覺，特別是在 Twitter 上被各種 AI 又做到了什麼事情、有人又用 AI 做了什麼酷東西等等資訊洗版時更是覺得快喘不過氣。

但今年的我開始放鬆看待一切，比別人慢就慢吧，等到有興趣時自然會去看，會突然有這種想法其實跟「MCP」這個概念有關，還記得年初時突然一堆人在討論 MCP ，以及吹捧它到底有多強。好像如果我只是單純地傳 prompt 給 AI 就會被顯得不夠會用 AI 。

但現在我覺得錯過了 MCP 好像一點損失都沒有，至少在日常開發體驗上現在已經有更多更好的工具及流程讓我不使用 MCP 也能讓我的效率提升了。當然我相信 MCP 一定還是有值得使用的場景，但好像不必每個團隊的每個東西都開發成一個 MCP server 吧？

打個預防針，或許是我不夠懂 MCP 才會有這些評論，如果覺得我有說錯地方那一定是我的錯。

對於 AI 的看法#

既然說到 AI 不如就來說說我對 AI 的看法其實一直以來我很少對 AI 發表什麼看法，一來是我真的不懂，二來是我對 AI 怎麼運作或如何實作也沒有太大的興趣，所以就是看看哪個 AI 工具能夠簡單使用並且有到提升一點效率就好，懶得研究到怎麼用最有效率或者更完美。

但即使對於 AI 發展沒那麼在乎的我也覺得今年它在提升開發效率上已經超乎我的想像了，或許現在我真的可以說如果沒有 AI 我可能真的無法好好地開發了。從年中的 claude code 開始就體會到時代真的不一樣了，現在工作時更多的時間是在想架構、想流程以及 review AI 的 code XD

除了工作，我也開始利用 AI 提升日常生活效率，這一切要歸功於 n8n 的出現，雖然它本質上是一個自動化工具但因為裡面可以將各種工作流很好地整合 ai agent 。目前我最常使用的工作流是自動摘要以及分析我收集文章或其他資料然後再寫入 notion 及通知到 DC ，這大大減低存了文章卻完全不讀的機率。

一再改變的筆記流程#

今年年中再次重新審視自己到底是如何寫筆記，發現自己真的沒有那麼常用或者那麼需要 heptabase ，當然，它絕對是一個很好的產品只是現在我好像沒有那麼需要它而已。或者該說是因為 notion 有其他不可替代性所以我才又回去了 。

這又要提到 n8n 了，可以說為了融入我現在的 AI 工作流所以我又將資料收集以及筆記的存放的地方改回去 notion 了，畢竟 notion 與其他外部服務的整合真的簡單很多 ，雖然說同時用兩個筆記軟體倒也不是不行，只是想想我也不是什麼筆記軟體的重度使用者並不想把自己的工作流程搞得如此複雜，所以如果哪一天 heptabase 有提供 API 讓使用者去串接外部服務的話或許我還會再回去的。

不要放棄前端#

今年花了很多時間在開發後端的功能但我還是蠻喜歡前端的，雖然不知道哪一年才會真正遇到「前端已死」但至少現在我還是會想花心力在前端領域的。

只是我可能會更想把時間放在 React 以外的框架特別是 Svelte ，畢竟現在工作上使用 Svelte 的機會愈來愈多了再加上對於 React 的厭惡日漸增長。但如果工作需要的話還是會繼續寫 React 吧，畢竟在台灣 React 相對於 Svelte 來說還是主流許多。

多寫文章#

雖然每年都這麼說但每年的產出依然少得可憐 XD，但今年感覺自己沒有特別給什麼壓力也能保持差不多的文章量，那感覺明年努力一點或許可以多寫一點文章。

最近愈來愈覺得寫文章除了是學習知識的途徑也是一種證明自己存在的方式，特別是在這個 AI 盛行的時代，直到目前為止我依然不太想讓 AI 幫我寫部落格連潤稿都不太想，頂多只有在寫某些我不太熟的概念時才會想去問 AI 。

之所以還想繼續自己撰寫內容，主要是我還是想保持著這種「粗糙的手作感」，想讓這些文章還保持「我」的味道。當然維持這種儀式感或者感性的部分在這個時代顯得相當沒有效率，但或許也是在這個時代中表現人性最好的方式吧 XD