Terry Yao's Blog

[career/02] 好的後端工程師需要什麼能力？不只是會寫 CRUD

閱讀時間約 11 分鐘

結論先講

好的後端工程師不是「會把資料從資料庫撈出來再吐回去」的人。是能設計穩定、安全、可擴展的系統的人。CRUD 是入門，不是終點。

如果你現在只會寫 SELECT * FROM users WHERE id = ?，不知道什麼是 N+1 query、沒想過 API 版本怎麼管理、從來沒處理過 race condition——那你大概還在「能動就好」的階段。

這篇幫你看清楚：好的後端工程師，到底需要什麼能力。

1. API 設計直覺：不只是選 RESTful

API 是你跟前端、跟其他服務溝通的介面。設計得好，大家都開心；設計得爛，改到天荒地老。

RESTful 的基本紀律：

  • GET 不要有副作用（不要用 GET 來刪除資料，真的有人這樣做）
  • URL 用名詞不用動詞：POST /orders 而不是 POST /createOrder
  • HTTP status code 用對：201 Created、204 No Content、404 Not Found、409 Conflict
  • 不要所有錯誤都回 200 OK 然後把 error 放在 body 裡

版本管理：

方式範例優缺點
URL path/api/v1/users清楚直觀，但 URL 會變
HeaderAccept: application/vnd.api+json;version=1URL 乾淨，但不好測試
Query param/api/users?version=1簡單，但不太標準

大多數團隊用 URL path，因為最直觀。不管選哪個，重點是要有，而且要一致。

錯誤處理：

好的 API error response 長這樣：

{
  "error": {
    "code": "INSUFFICIENT_BALANCE",
    "message": "帳戶餘額不足",
    "details": {
      "required": 1000,
      "available": 350
    }
  }
}

不是這樣：

{
  "success": false,
  "message": "Error"
}

設計 API 的時候，想像你是要用這個 API 的前端工程師。你會想收到什麼樣的 response？

2. SQL 不是只有 SELECT

會寫 SELECT * FROM users 不代表你懂資料庫。

Indexing（索引）：

  • 知道什麼欄位該加 index（WHERE、JOIN、ORDER BY 常用的欄位）
  • 知道 composite index 的欄位順序很重要（最左前綴原則）
  • 知道 index 不是越多越好（每個 index 都有寫入成本）
  • 會用 EXPLAIN 分析查詢計畫

Query 優化：

問題症狀解法
N+1 Query列表頁超慢，SQL 數量跟資料量成正比用 JOIN 或 eager loading
**SELECT ***撈了一堆不需要的欄位明確指定需要的欄位
沒有 index全表掃描加 index，用 EXPLAIN 確認
大量 IN 查詢IN 裡面幾千個 ID改用 JOIN 或 temp table
LIKE ‘%keyword%‘index 無法使用考慮全文搜尋（Full-text search）

Migration（資料遷移）：

  • 不要手動改 production 的 schema
  • Migration 要可以 rollback（up 和 down）
  • 大表加欄位要小心（可能鎖表）
  • 資料遷移和 schema 遷移要分開做

3. 並發思維：不是只有你一個人在用系統

當多個 request 同時來，或多個 worker 同時處理任務，事情就會開始有趣了。

Race Condition 經典案例：

兩個人同時搶最後一張票：

  1. A 讀取庫存 = 1
  2. B 讀取庫存 = 1
  3. A 把庫存改成 0，下單成功
  4. B 把庫存改成 0，下單成功
  5. 結果：賣了兩張票，但只有一張

解法選擇：

方法適用場景代價
Pessimistic Lock（悲觀鎖）衝突頻繁效能較差，可能 deadlock
Optimistic Lock（樂觀鎖）衝突少需要重試機制
Queue需要順序處理增加延遲和複雜度
Atomic Operation簡單計數器場景有限

Deadlock 怎麼避免：

  • 所有地方用相同的順序取鎖
  • 設定 lock timeout
  • 減少鎖的粒度和持有時間

真實案例：某支付系統因為沒處理 race condition，同一筆退款被執行了兩次。修復方式是加上 idempotency key——每個退款請求帶一個唯一 ID，重複送不會重複執行。

4. 除錯方法論：不是靠運氣

Junior 的除錯方式：改一行跑一次，看有沒有好。 Senior 的除錯方式：先假設，再驗證，有系統地縮小範圍。

系統化除錯流程：

  1. 重現問題：能穩定重現是解決問題的一半
  2. 看 log：不是 print("here")，是結構化的 log（時間、request ID、user ID）
  3. 縮小範圍：是哪一層的問題？網路？應用程式？資料庫？
  4. 假設與驗證：「我猜是 cache 的問題」→ 繞過 cache 試試
  5. 修復與驗證：修完要確認問題真的解決了，不是剛好消失了

好的 Log 長這樣：

2026-03-15 10:23:45 [ERROR] [req:abc123] [user:456]
  PaymentService.charge failed: insufficient_funds
  amount=1000 balance=350 payment_method=credit_card

不是這樣：

Error: something went wrong

Profiling 工具你該知道的：

  • APM 工具（Datadog、New Relic、Sentry Performance）
  • 資料庫 slow query log
  • 火焰圖（flame graph）看 CPU 消耗
  • Memory profiler 抓 memory leak

5. 系統設計基礎：不是只有面試才用到

即使你不是架構師，你也需要理解這些概念，因為你每天都在一個分散式系統裡工作。

Caching（快取）：

層級工具適用場景
Application cacheRedis / MemcachedSession、熱門資料、rate limiting
HTTP cacheCDN / Browser cache靜態資源、API response
Database cacheQuery cache / Materialized view複雜查詢結果

Cache invalidation 是電腦科學兩大難題之一（另一個是命名）。你至少要知道 TTL、write-through、cache-aside 這幾種策略。

Message Queue：

  • 什麼時候該用：任務不需要同步回應（寄 email、處理圖片、產生報表）
  • 常見選擇：RabbitMQ（簡單可靠）、Kafka（高吞吐量）、Redis Queue（輕量）
  • 要考慮的：retry 策略、dead letter queue、冪等性

Load Balancing：

  • Round Robin vs Least Connections vs IP Hash
  • Health check 的重要性
  • Session affinity（sticky session）什麼時候需要

6. 安全意識：不是資安團隊的事

安全不是加分項，是底線。

漏洞類型你該做的常見錯誤
SQL Injection用 parameterized query字串拼接 SQL
XSS輸出時 escape信任用戶輸入
CSRF用 CSRF token只靠 cookie 認證
Auth 漏洞用成熟的 library自己實作 JWT 驗證
Secrets 洩漏用環境變數或 vault寫死在程式碼裡
IDOR每個 API 都檢查權限只檢查登入狀態

密碼儲存：

  • 用 bcrypt/argon2 hash，不是 MD5 或 SHA256
  • 不要自己發明加密演算法
  • Salt 要隨機產生，不要共用

API 認證：

  • JWT 不要放敏感資訊在 payload（它只是 base64，不是加密）
  • Token 要有過期時間
  • Refresh token 的安全儲存（httpOnly cookie）

安全的第一原則：永遠不要信任用戶輸入。不管是 request body、query parameter、header，都要驗證和清理。

7. Junior vs Senior 能力對比表

面向JuniorSenior
API 設計能寫出可以用的 API設計一致、好用、有版本管理的 API
SQL會 SELECT/INSERT/UPDATE會優化查詢、設計 schema、處理 migration
並發不太考慮主動考慮 race condition，選擇適當的鎖策略
除錯靠 print 和運氣系統性分析，善用工具
系統設計不太了解能做技術選型，理解 trade-off
安全知道要注意但不確定怎麼做開發時就考慮安全，code review 會抓漏洞
錯誤處理能跑就好設計完整的錯誤處理策略和 fallback
文件覺得是浪費時間寫 API 文件、架構文件、runbook

FAQ

Q1: 後端要學幾種程式語言？

精通一個，了解一到兩個。語言是工具，重要的是你對系統設計、資料庫、網路這些概念的理解。如果你精通 Python，能用 Go 寫簡單的服務，那就很好了。

Q2: 要學 NoSQL 嗎？

了解 NoSQL 的適用場景很重要（文件型、Key-Value、時序），但大多數業務場景用關聯式資料庫就夠了。不要因為 MongoDB 比較潮就選它。先確定你的資料模型適不適合。

Q3: 微服務是不是比 Monolith 好？

不一定。微服務解決的是組織擴展的問題，不是技術問題。如果你的團隊只有五個人，monolith 可能更適合。Martin Fowler 說過：「要先有一個好的 monolith，才值得拆成微服務。」

Q4: 後端需要懂 Docker 嗎？

2026 年，是的。你不需要變成 DevOps 專家，但你要能寫 Dockerfile、用 docker-compose 建立開發環境、理解 container 的基本概念。這已經是基本技能了。

Q5: 從後端轉 SRE/DevOps 容易嗎？

相對容易，因為你已經理解應用程式怎麼運作。需要補強的是 Linux 系統管理、網路、IaC 工具、監控系統。這篇系列的第三篇會講到 Infra/DevOps 需要的能力。

系列導航

關係圖譜

反向連結