2025年6月11日
•5分鐘閱讀
對於擔任前端工程師，算是剛邁入一年的時間。因此想要藉由這個空檔，回顧一下上半年的學習和工作。
| 分類 | 說明 |
|---|---|
| Framework | Next.js, React + Vite, Astro |
| UI Framework | Tailwind CSS ,Radix UI, Shadcn UI ,Material UI |
| State Management | Redux, Zustand, Jotai, Tanstack Query, Context API |
| Headless CMS | Strapi |
| Map | DeckGL, MapLibre GL |
| Other | i18n-next, zod, Google Tag Manager, Web Recognization API |
| 內部服務 | Outline, Docusaurus |
| Testing | Playwright, Vitest |
有時候像是 Google Translate API 等 Token 適合藏在 Server，或是整個專案的業務邏輯 Google 不到，只有我會寫。因此在不考慮高併發的時候（要花點時間去規劃），會寫一些後端來給自己的前端串接，或是測試一些 MVP。
| 分類 | 說明 |
|---|---|
| Framework | Next.js (API Route), Express.js |
| ORM | Prisma, Drizzle ORM |
| API | REST, GraphQL, Swagger UI, WebSocket |
| Database Service | Neon, Supabase, PostgreSQL, MySQL Workbench |
| Map | TileServerGL |
| Other | zod, jwt, MCP Server, docling |
目前的主力還是放在 Web Frontend，不過前陣子因為要寫擴充套件的需求，開始學習一點 Kotlin，發現某些功能的寫法跟 React 很像。還有相較於 Web Vitals，Google Store 也有相對應的評分機制，這點也很有趣。
| 分類 | 說明 |
|---|---|
| App | Kotlin, kotlin coroutine, Jetpack Compose |
| Other | Retrofit |
現在的公司，不知道是不是比較資深，每個工程師都會管自己的 VM，同時開發初期也需要自己寫 Dockerfile 或是管理 CI/CD 的流程，因此也花了一點時間學習如何處理環境的問題。不過好處是，有時候看到有趣的開源專案，可以很快的自己開一個 EC2 或是 Zeabur 下來玩。
| 分類 | 說明 |
|---|---|
| CI/CD | Docker Compose, Gitlab CI |
| VM | Ubuntu, VIM |
| Proxy | Nginx Manager, Certbot |
| Cloud Service/Bucket | AWS(EC2, S3), Cloudflare R2, Digital Ocean, Minio |
| Domain | Namecheap |
雖然很多人都說先決定公司，再跟著制度去學習，但就跟買菜一樣，很多事情是可遇不可求的，如果沒以這個環境怎麼辦？
大概有好一陣子，團隊缺少專業的 PM，工程師要直接面對甲方的需求，我也在反思：『要怎麼去框實際的需求？』、『除了 A4 紙草率的紀錄外，什麼是好的文件？』
使用 PRD 去 Google ，並經歷了一番挫折後，找到了一個比較看得順眼的範本(kevinyien: PRD Template)：
喜歡的原因是
# \[專案名稱\]
## **\[一行描述\]**
\
\
團隊：\[Awesome\]
貢獻者：\[專案經理\]、\[設計師\]、\[工程師\]、\[分析師\]
資源：\[設計文件\]、\[分析數據\]、\[筆記\]
狀態：**草稿** / 問題審查 / 解決方案審查 / 上線審查 / 已上線
最後更新日期：2020 年 5 月 21 日（星期四）
---
# 問題對齊
| 請用 1-2 句話描述我們試圖解決的問題。我應該能夠單獨閱讀這部分，並向他人傳達該問題的價值與風險。這對我們的客戶和業務有何重要性？您有何證據或見解來支持這一點？ |
|:---|
## 高層次方法
| 描述我們可能解決此問題的大致方向。我應該能夠模糊地看出大致方向。例如，如果問題是"新功能的可發現性"，那麼解決方案可能是"一個通知中心來顯示相關功能"。 |
|:---|
## 敘述
| （可選）透過假設性故事描述客戶當前的使用情境，展示他們的現況。描述常見和極端的使用案例，以便在設計解決方案時加以考慮。 |
|:---|
## 目標
1. *描述高層次目標，最好按優先順序排列，且不要太多。*
2. *包括可衡量（指標）和不可衡量（感受）的目標*
3. *保持簡明扼要*
##
## 非目標
1. *列出我們不計劃解決的範圍*
2. *說明這些範圍為何不在目標內*
3. *這些非目標與目標一樣重要且具有明確性*
| 🛑 若所有貢獻者尚未對問題達成共識，請勿繼續。🟢 完成以下表格，並獲得所有審閱者的"簽名"以繼續。 |
|:---|
| 審閱者 | 團隊/角色 | 狀態 |
|:---|:---|:---|
| | | |
| | | |
# 解決方案對齊
| ✅ *劃定範圍* | 🚫 *不要強迫他人定義範圍* |
|:---:|:---:|
| | |
## 核心功能
正式方案
1. *列出構成解決方案的核心功能*
2. *最好按優先順序排列*
3. *將其視為定義解決方案範圍的方式*
4. *劃定界限，以便團隊可以專注於如何填補這些內容*
5. *對於特別大的專案，請鏈接到詳細的子文件*
6. *挑戰範圍，看看是否可以先獨立推出較小的部分*
未來考量
1. *可選擇性地列出未來可能考慮的功能*
2. *這些可能影響當前的開發方式*
## 核心流程
| 展示客戶的端到端體驗。這可以是書面描述、流程圖、螢幕截圖或設計探索，具體表現形式將取決於專案和團隊。請勿獨自完成此部分，應與設計和工程團隊共同完成。此部分的內容會隨時間變得更具體，可能一開始只是幾個附註的截圖或故事，後續可能發展為具體的需求和驗收標準。請根據團隊的運作方式進行調整。如果設計師願意深入探索每個邊緣情境，就依賴他們；如果工程師希望詳細記錄每種情境，就深入描述驗收標準。這個部分會隨時間變化，這是正常的。當發生變更時，請在 [變更記錄]() 中記錄，並通知所有貢獻者。 |
|:---|
## 核心邏輯
1. *列出指導設計和開發的規則*
2. *處理常見情境和邊緣案例*
3. *通常以文字描述這些邏輯比僅依賴設計來呈現每種變化更容易*
| 🛑 若所有貢獻者尚未對問題達成共識，請勿繼續。🟢 完成以下表格，並獲得所有審閱者的"簽名"以繼續。 |
|:---|
| 審閱者 | 團隊/角色 | 狀態 |
|:---|:---|:---|
| | | |
| | | |
# 上線計劃
| 定義將產品推向市場的各個階段，每個階段的目的，以及必須滿足的標準才能進入下一階段。強調可能影響時程或進度的風險和依賴關係（以及理想的應對計劃）。以下是示例階段表。 |
|:---|
## 主要里程碑
| 目標日期 | 里程碑 | 描述 | 退出標準 |
|:---|:---|:---|:---|
| YYYY-MM-DD | ✅ 試點 | 僅限內部員工測試 | 連續 7 天無 P0 或 P1 級錯誤 |
| YYYY-MM-DD | 🛑 測試版 | 20 名早期客戶 | 至少有 10 位客戶表示如果移除該功能會感到失望 |
| YYYY-MM-DD | 🛑 早期使用 | 來自銷售團隊的邀請制客戶 | 在每個主要競爭對手中至少取得 1 項勝利 |
| YYYY-MM-DD | 🛑 正式上線 | 所有當前市場的客戶 | 監測並衡量影響 |
## 營運清單
| 團隊 | 提示 | Y/N | 行動（若是） |
|:---|:---|:---|:---|
| 分析 | 是否需要額外的追蹤？ | | 與 \[負責人\] 合作記錄數據 |
| 銷售 | 是否需要銷售啟動資料？ | | 與 \[負責人\] 合作 |
| 行銷 | 是否影響共享 KPI？ | | 與 \[負責人\] 合作調整目標 |
# 附錄
## 變更記錄 {#變更記錄}
| 日期 | 描述 |
|:---|:---|
| | |
| | |
## 開放問題
記錄開放問題及其解答。
## 常見問題
（可選）提供常見問題解答，幫助讀者快速理解專案要點。
影響檢查清單
* 權限
* 報告
* 定價
* API
* 全球化
## 示例 PRD
待補前陣子讀書為了要解釋比較複雜的概念，常常需要畫流程圖，因此開始尋找適合的工具。不知道因為英語相較於亞洲人，更喜歡文字表達的關係，因此常常需要使用圖表來取代 AI 產生的文字。
這個算是前陣子才發現的技巧，在 Vibe Coding 完之後，可以告訴 Agent：『請幫我總結這次的 API 路徑開發，整理成 Postman 的客戶端使用範例，並提供成功、失敗的範本』
{
"info": {
"name": "用戶 API",
"schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
},
"item": [
{
"name": "GET 用戶列表",
"request": {
"method": "GET",
"url": "{{base_url}}/users"
}
},
{
"name": "POST 創建用戶",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json"
}
],
"body": {
"mode": "raw",
"raw": "{\n \"name\": \"張三\",\n \"email\": \"test@example.com\"\n}"
},
"url": "{{base_url}}/users"
}
},
{
"name": "GET 單一用戶",
"request": {
"method": "GET",
"url": "{{base_url}}/users/1"
}
},
{
"name": "PUT 更新用戶",
"request": {
"method": "PUT",
"header": [
{
"key": "Content-Type",
"value": "application/json"
}
],
"body": {
"mode": "raw",
"raw": "{\n \"name\": \"李四\",\n \"email\": \"updated@example.com\"\n}"
},
"url": "{{base_url}}/users/1"
}
},
{
"name": "DELETE 刪除用戶",
"request": {
"method": "DELETE",
"url": "{{base_url}}/users/1"
}
}
],
"variable": [
{
"key": "base_url",
"value": "https://api.example.com"
}
]
}終於不用追著後端要 Swagger 了
直觀上也比 Swagger 好操作（儘管 Swagger 的目的不完全一樣，是為了讓後端的 API Spec 文件更完整）
在前面已經初步擬定好 PRD 後，由於通常專案會有依賴性、先後順序，可以透過 MCP Tool 來分析和拆分任務，算是覺得這陣子最實用的 MCP Tool。
- Parse requirements: Can you parse my PRD at scripts/prd.txt?
- Plan next step: What's the next task I should work on?
- Implement a task: Can you help me implement task 3?
- Expand a task: Can you help me expand task 4?
大概是半年前，曾經與其他廠商的工程師討論過，他覺得工程師最大的職責是劃定好邊界，還有告訴業主哪些可以做、哪些辦不到。
其實 RD 跟很多人一樣，碰到特定的業務邏輯、或是沒學過的技術，還是要先花時間去研究 API 文件、相關的 GitHub Discussion，才知道特定功能實際上能不能實現，特別是初始的需求很模糊的時後。
以自己來說，如果遇到地圖的需求，第一步會先對於需求做初步的訪談，試著抓出最基本的功能性需求：
…
接著透過假資料，去測試一千台 3D 敞篷車在地圖上，來測試核心功能在最糟糕的狀態下會不會爆炸？或是試想其他沒有在畫面上的考量，例如：caniuse 的支援程度等。
回顧 RD 的本質：應該要先 Research 然後再 Design，即便 AI Agent 盛行，終究 RD 是最後要負責的人。
有點像是回到大二修『社會科學研究方法』的時候，很多問題真的沒有正確答案，需要先釐清假設，然後才去回答。
做過社會科學研究的大概都知道，最難處理問題的不是資料，而是『人』，這大概是百工百業不變的課題吧ＸＤ
回顧這半年，這些是自己覺得在冥冥之中幫助很大的課程：
對很多前端來說，由於 Vercel 等平台很方便，一建就部署完成，因此 Server 很像一個黑盒子。這個課程算是以前端的角度出發，去完整跑完 Server 架設的流程。
這陣子發現不管是 React 或是 Kotlin，最核心的都是如何去設計資料流、畫面重繪（Reconciliation）的邏輯。
老實說不是因為很實用，而是看過這本書所以知道像是 Worker API、 Backend For Frontend、 iframe 等之前比較少接觸的技術。遇到一些很瞎的需求，腦袋會有警鈴大響這個操作打破了瀏覽器規則。
面對 Agent 系列的產品，除了透過 ExplainThis 電子報、白皮書去補理論外，這一系列的影片算是比較入門怎麼清理資料的影片。
除了推 Git 外，很多時候還是很慶幸生活中的小確幸：
淡水老街、七星山、草嶺古道、和平島公園、西子灣、澎湖、九份 …
就像早期的工業革命，取代了生活中很多繁重的勞動，希望未來 AI Agent 也能替我們取代情緒勞動，讓我們有更多時間去投注更有意義的事情。