Joel Spolsky（Joel on Software 作者、Stack Overflow 聯合創始人）提出的「Joel Test」—— 12 條簡單是非題，三分鐘即可診斷軟件團隊工程成熟度。微軟內部長期沿用，得分 12 分為優秀，11 分合格，≤10 分隱患嚴重。業界平均僅 2-3 分。本文逐條深度解析與落地指南。
12 條測試題（每條是=1分，否=0分）
- 源碼控制：你們用源碼控制系統嗎？（Git/SVN/Perforce...）
- 一鍵構建：能一步從源碼構建到發布包/鏡像嗎？
- 每日構建：每天自動構建發布包嗎？
- 缺陷追蹤：有 Bug 追蹤系統嗎？（Jira/Bugzilla/GitHub Issues...）
- 先修 Bug 後寫新代碼：寫新功能前，先修清現有已知 Bug 嗎？
- 項目進度表：有反映最新進展的項目計劃表嗎？
- 功能規格書：有具體的功能規格文檔嗎？
- 安靜環境：程序員有安靜獨立工作環境嗎？
- 最佳工具：用市面上買得到的最好工具嗎？（IDE、顯示器、椅子、CI/CD...）
- 專職測試：有專職測試人員嗎？
- 面試寫代碼：招聘面試要求寫代碼嗎？
- 走廊測試：隨便抓路人試用軟件嗎？（可用性測試）
逐條深度落地指南
1. 源碼控制：不只是備份，是協作基礎設施
- 分支策略：Git Flow / GitHub Flow / Trunk-Based Development
- 提交規範：Conventional Commits，關聯 Issue ID
- Code Review：Merge Request / Pull Request 強制審查
- 二進制資產：大文件用 Git LFS 或獨立制品庫
2. 一鍵構建：消除「在我機器上能跑」
- 構建腳本：Maven/Gradle/Bazel，單命令
./build.sh 產出制品
- 環境隔離：Docker 構建環境，鎖定 JDK、工具鏈版本
- 制品輸出：JAR/WAR/Docker Image/Helm Chart，版本號自動注入
- 可復現性：同一 Commit 多次構建產出位元級相同制品
3. 每日構建：及早發現集成地獄
- CI 流水線：每次 Push 觸發構建+測試+靜態分析
- 夜ly 構建：全量測試、性能基線、安全掃描、文檔生成
- 構建失敗 = 最高優先級中斷，責任人立即修復（微軟「罰值班」文化）
- 制品推送：構建成功自動推送到制品庫/測試環境
4. 缺陷追蹤：Bug 不能只存在腦海/郵件/聊天記錄
- 標準字段：標題、復現步驟、預期/實際、嚴重級、優先級、環境、標簽
- 生命週期：New → Triaged → In Progress → Fixed → Verified → Closed
- 關聯性：Bug ↔ Commit ↔ PR ↔ Release Note ↔ 測試用例
- 指標：Bug 積壓趨勢、修復週期、逃逸率、重開率
5. 先修 Bug 後寫新功能：債務優於新投資
- 零 Bug 政策：發布分支零已知嚴重 Bug
- 技術債務顯性化：專門 Sprint/配額償還債務
- 「破窗理論」：容忍一個 Bug = 邀請更多 Bug
6. 項目進度表：誠實面對現實
- 敏捷工具：Jira Board / Azure Boards / GitHub Projects
- 燃盡圖/燃起圖：可視化進度與風險
- 定期回顧：根據速度調整範圍，而非壓縮估算
- 透明化：利益相關者可見實時狀態
7. 功能規格書：思考優於編碼
- 輕量規格：README + API 契約 + 關鍵流程圖 + 驗收標準
- 活文檔：代碼即文檔（Swagger/OpenAPI、Architecture Decision Records）
- 評審機制：開發前規格評審，發現邏輯漏洞成本最低
8. 安靜環境：深度工作的前提
- 物理隔離：獨立工位、降噪耳機、站立式桌椅
- 時間保護：無會議日、專注時間塊、異步溝通優先
- 遠程友好：文檔化決策、錄屏分享、時區感知協作
9. 最佳工具：工欲善其事，必先利其器
- IDE：IntelliJ IDEA Ultimate / VS Code + 插件包
- 硬件：雙 4K 顯示器、機械鍵盤、人體工學椅、M2 SSD
- 雲開發：GitHub Codespaces / Gitpod 統一環境
- 觀測性：Grafana + Prometheus + Jaeger + ELK
10. 專職測試：開發 ≠ 測試
- 測試金字塔：單元(70%) → 集成(20%) → E2E(10%)
- 測試左移：需求階段介入、契約測試、混沌工程
- 自動化優先：CI 門禁、覆蓋率門檻、變異測試
- 探索性測試：專職 QA 發現自動化覆蓋不到的邊界
11. 面試寫代碼：拒絕「會背八股文」
- 現場編程：LeetCode 風格 + 系統設計 + 代碼評審
- 結對編程：觀察思維過程、溝通協作、工具熟練度
- 取家作業：實際項目片段、Code Review 模擬
- 軟技能：行為面試 STAR 原則、價值觀對齊
12. 走廊測試：真用戶最懂產品
- 可用性測試：5 個用戶發現 80% 問題 (Nielsen Norman Group)
- 原型驗證：Figma 原型 → 真機測試 → A/B 測試
- 無障礙檢查：WCAG 2.1 AA 標準、屏幕閱讀器實測
- Dogfooding：團隊每天用自家產品
評分解讀與行動建議
| 得分 | 狀態 | 行動 |
|---|
| 12 | 🏆 世界級 | 保持持續改進，輸出最佳實踐 |
| 11 | ✅ 合格 | 針對扣分項制定整改計劃，季度複查 |
| 8-10 | ⚠️ 亞健康 | 優先解決 1-4 條基礎設施項，建立 CI/CD/源碼控制/Bug 系統 |
| 5-7 | 🚨 重症 | 管理層介入，重組流程，外部教練輔導 |
| 0-4 | ☠️ 瀕死 | 停止新功能開發，全員整頓工程基礎設施 |
避免誤用
⚠️ Joel Test 不適用於：核電站控制系統、心臟起搏器固件、航飛控制軟件等安全關鍵系統。這些領域需要 DO-178C、IEC 61508、ISO 26262 等嚴格認證體系，而非 12 條啟發式檢查表。
但對 99% 商業軟件項目，它是最高性價比的健康度儀表盤。
下次團隊回顧會，花 3 分鐘跑一遍 Joel Test，比任何冗長報告都更直擊要害。
