開發團隊到底好不好，這 12 個問題能檢驗出來嗎？

「Joel 測試」是 Joel Spolsky 在 2000 年提出的 12 個問題，用來檢驗一個團隊是否是好的開發團隊。17 年過去了，Dale Myers 重新審視了這12個問題，並與時俱進地提出了修改建議。

---

就在 2013 年，我參加了一個課程：“軟體的架構、執行和管理”。其中主題之一，就是如何評價一個開發團隊？這不是一個簡單的問題，如果要得到一個完整的答案，最後一定需要一些必要的研究，一篇冗長的報告。還好，Joel Spolsky 提出了12 個非常簡單的測試問題，相對無痛地解決這個問題，這些問題被稱為“Joel 測試”。該測試不是非常嚴謹，也無意於此。但是它可以為你提供堅實基礎，進一步瞭解其他細節。

Joel 測試的優點在於：僅僅通過很小一組是非題，就可以得到需要的答案。你無需關注任何例外，或任何附加條件，只需要單純的關注每個問題的答案是 yes 還是 no，就可以得到需要的結果： 12 分為優，11 分為良， 10 分及以下為差。這個優點並沒有被我和我的幾個同學忽視。我立刻將這個方法用到評估那些我面試實習的公司，以及後來畢業後第一份工作的公司。大多數僱主從來沒有聽說過這個測試，這倒不意外。真正令人意外的是，有多少公司沒有通過該測試，而我曾認為這些公司非常棒！

我提問的不準確嗎？他們真的理解我的意思嗎？再或者我統計 12 個問題的時候算錯了？

在面試時遇到 ”你還有什麼想要問我們的嗎？“ 這種問題時，Joel 測試是回答這個問題的大殺器，但是基本都沒有及格的。當然，有可能剛好我面試的公司都很差勁，但是，儘管我是軟體行業的新人，但是我有個感覺，事實絕非如此。我將該測試帶入我的一些應用，發現我竟沒有在任何地方考慮到這些問題。

那麼我在 Joel 測試中出了什麼問題呢？

每個開發人員都是不同的，他們對好壞都有著自己的標準，而且這個標準還會隨著時間變化。Joel 測試試圖規避這種偏差，用客觀題替代了主觀題。相信沒有任何開發人員會反對，跟蹤 bug 是個好想法，但是其他的問題呢？

從 2000 年釋出開始，Joel 測試已經有 17 個年頭了。它比 OS X 的歷史還要久。在同一時期，Windows 2000 還是當時技術最高水平，PlayStation 2 剛剛釋出， 奔騰 III 處理器還在 1GHz 下嗡嗡地工作。 在計算機世界裡，這確實是很久以前的事了。隨著處理器計算能力（還有硬體的整體效能）每18個月翻番，我們的開發程式也一同提升了。Joel 測試的問題反映了當時軟體開發的時代縮影。時至 2017 年，它們就未必非常恰當了。

以第一個問題為例：

是否有原始碼控制？

如今最流行的版本控制系統——Git，在當時還沒有出現。好吧，眾所周知，Git 直到 2005 年才出現。也不要忘記，前任的版本控制系統之王——Subversion 也是到 2000 年才出現，比 Joel 測試首次釋出晚了 2 個月。那時原始碼控制出現了，但是卻不像今天這樣普遍。這是不是意味著，今天還討論原始碼控制這個問題顯得多此一舉呢？可能吧！我們應該修改這個問題與時俱進嗎？也許吧！

讓我們一起來看看這些問題，然後看看如何與時俱進吧。

1. 是否使用原始碼控制？

除了上面提到的，時至今日，這個問題似乎依然有意義。任何團隊都需要原始碼控制，這是毋庸置疑的。如今的爭議主要在是否使用集中式版本控制系統。一般的專案使用 Git 或者 Mercurial （舉例來說）都可以。大型公司擁有超大型程式碼倉庫，一般採用集中式版本控制系統。這個問題沒有絕對答案。真正重要的是，有版本控制！既然這個問題已經是常識，我認為它就沒必要繼續存在了。

更新建議： 刪除

2. 能實現一鍵編譯嗎?

Joel 的解釋如下：

從最新的程式碼快照編譯出交付版本，一共需要多少步？

其背後的原因，今天依然成立。好了，我認為這是我們對老問題的第一個挑戰。我一直認為，編譯交付版本，應當 0 步驟完成。持續整合已經廣泛存在。使用它是非常明智的。建立一個交付版本的步驟應當這樣：程式設計師們提交程式碼，當管理人員，或者其他負責人準備 release 時，他只需要點選 ”release“ 按鈕即可，然後就成功了。所有開發人員只需要確保他們提交的程式碼無誤，持續整合服務自動會完成其他工作。

持續整合系統將軟體開發產業向前推進了一大步。如果我們能更廣泛的使用，充分發揮它的潛力，我們將受益良多。

更新建議：所有版本，都由持續整合伺服器自動編譯嗎？

3. 是否進行每日編譯？

這個問題緊隨第 2 個。如果對團隊有用的話，每日編譯是可行的。我一直認為每日應當是最低限度了。在我眼裡更好的實踐是，確保主開發分支的每一次提交，都可以正常的完成編譯。這算是一種“預覽”版本，同時也意味著你能更快、更有效地發現自己的問題，因為一旦發生任何故障，非常容易確認其版本。

該編譯過程應當由持續整合系統自動完成。還有，你不止應當進行每日編譯，而且應該使用它們。當然，如果你開發那些與你日常工作無關的軟體時（定製或者專業軟體），很難做到這一點。比如你在開發一款會計軟體，或者火箭控制程式，顯然你不可能使用這些產品。然而，我的建議是，每天至少花20分鐘看看你的軟體，試用一下，確保一切正常。假如你開發的軟體每天都能用得到，那就更好了。它的作用與前面提到的 20 分鐘試用一樣，但在實際操作中，你可以進行遠超 20 分鐘的測試，使專案暴露在更加真實的場景下。

更新建議：是否執行每日編譯，並使用這些版本？

4. 有無 bug 資料庫？

當然啦，你應該使用某種 bug 資料庫。你聽說過任何人認為沒這個必要嗎？如今發生變化的是，bug 跟蹤有了更加豐富的特性。它們已經不再單單是一個資料庫表的介面，而是擁有豐富功能的規劃、管理程式，通常在任務和 bug 之間有顯著區別（參考第 5 條）。

如今，當你提交一個bug時，它有標題、描述、復現步驟、影響平臺等等資訊，一般都是如此。如今不同的是，管理將貫穿你的 bug 處理，bug 會被分派到若干迭代中，你需要利用看板規劃任務，你的敏捷開發組長會就那些有困難的任務與你進行談話。

問題跟蹤器也不僅僅是記錄需要做的事。它包含誰執行了操作，對團隊的影響，對產品的影響，以及其他上百個屬性。那麼，我認為你應該有某種軟體來做這些事情，這都不重要，它就是你的某種問題跟蹤器。因為各個團隊的情況有所差異，這個問題也沒有確切的答案。我所做的一點調整，只是為了用文字的一點不同，來反映我們現有的能力。

更新建議：你是否使用問題追蹤器（issue tracker）？

5. 在編碼前是否解決bug？

Joel 對這一點的重要性給出了非常好的論述，17 年後的今天，它依然成立。

更新建議：無

6. 是否有實時更新的計劃表？

作為開發人員，你可能沒那麼關心計劃表。如果你的團隊沒有在按時完成任務會怎樣？不是你的問題嗎？把這個問題留給管理人員吧！

留個管理人員，也許有用，也許沒用。如今，我們有各種敏捷開發理論，從開發人員，或者其他任何估時比較靠譜的人那裡，得到的專案預估，是進行專案規劃的關鍵要素。這幫助我們安排團隊工作、誰來做這些工作，以及何時做這些工作。你可以掩耳盜鈴，假裝事事與你無關，但是最終，每一個人都需要對整個團隊有一份責任。

這一條今天還有效嗎？必須的！當然了，我們已經不用瀑布流了。確保準時達到測試階段，對我們已經沒有太多意義了，但在敏捷開發（很多人深信，跟“現編現造”一個意思），特別是敏捷開發，計劃表是最重要的，而且需要時刻保持更新。如今不同的是，計劃表會根據新資訊，保持更新。

更新建議：無

7. 是否有文件？

計劃表那一條完整的被保留下來，文件卻未必同樣走運。在瀑布流流行的時候，文件是你瞭解開發目標的關鍵。如果你無法有效調配資源，那麼你的專案，註定會失敗。

回到 2001 年，當你建立一個程式時，無論是一臺咖啡機，一臺火箭，或者只是一個簡單的 CRUD（Create、Retrieve、Update、Delete等） 介面，你都很清楚需要做什麼，以及大約需要多少開銷，逐步實現它。開發人員、測試人員、專案管理人員各司其職，大家全程根據文件展開工作，測試，交付，然後進入下一個專案。而今，在很多方面已經不是這樣了。當然了，如果你還在開發上面提到的東西，情況就基本沒什麼變化。但是，如果你在開發 Twitter 客戶端呢？或者文字編輯器呢？再或者郵件客戶端？以前的老方法還依然有效嗎？通常不是。

只有當你可以從一開始就獲得所有資訊，並用來完成規劃，文件才是有效的。當你的軟體需要持續開發時，文件只在 MVP（Minimum Viable Product，最小可行產品）階段比較重要，在此之後，它的用處就很小了。要讓文件在今天依然保持重要性，就必須實時更新資訊，並相應地適應當前進度和產品情況。

這裡所謂的資訊，可以通過很多形式獲得。可能只是簡單的模擬使用者如何使用APP，或者應該更進一步，如果可能的話，應當對新特性和設計進行 A/B 測試。

更新建議：是否有關於產品功能和使用相關的最新資訊？

8. 程式設計師有安靜的開發環境嗎?

當回想八九十年代的軟體開發環境，一片小隔間的海洋就會進入腦海。如今，情形基本沒變，唯獨發生變化的是，隔斷變得更小了，或者隔斷在所謂的“開放式”辦公室裡，直接消失了。

我個人而言，我並不喜歡開放式辦公室。我喜歡自己的辦公室，我就可以擁有單獨的開發時間，完全看我的喜好，我可以開啟音樂，讓我步入狀態。然而並不是所有人都同意我的觀點。我知道很多人喜歡開放式辦公，這樣更加有效率，促進團隊成員之間直接溝通，通常可以獲得更快、更好的問題解決方案。

這條規則對工作環境的要求，並不是什麼特例。開放式辦公室，通常比你自己的辦公室更加嘈雜。每當有人問起關於開放式辦公室的噪音問題時，我通常的解決方案就是帶上耳機。通過消音技術，基本能解決絕大多數問題。這是我平常在開放辦公室的辦法。

總之，安靜的工作環境，無非就是獨立辦公室和開放辦公室之間的取捨，這兩個也沒有孰優孰劣。

（ 《國內程式設計師的辦公桌是什麼樣的？》文中黃釗的曬圖 ）

更新建議：刪除

9. 是否使用市面上最好的工具？

這一條是最難取捨的，事實上我是寫完本文其他部分以後，才回頭寫這一部分。

我通常遇到的情況是這樣的，公司無法負擔市面最好的工具。也就是今天無法負擔而已，不代表以後不行。我認為這一條規則的精神依然是成立的。公司應當有義務，儘可能保證開發人員的工作愜意、開心。愉快、寬鬆的程式設計師會生產更好的程式碼。

有一點一定要切記，這並不意味著必須要用重金砸向這些問題，如果優秀的工具是免費的，那肯定還是要用免費的。

 

（《國外程式設計師的辦公桌是什麼樣的？》，網友「土豆」曬圖）

更新建議：無

10. 是否有測試人員？

不同公司在測試方面是有區別的。幾年前，就在我還是個實習生，到成為全職之間那段時間，微軟複用工程師作為測試人員。我曾撰文說明，為什麼我認為微軟複用開發和測試人員，很好的說明我作為實習生浪費了多少資源，還消除了曾鼓勵我編寫更好程式碼的安全網。現在這都在微軟得到印證，我們還是看看 Joel 對此是怎麼說的：

如果你的團隊沒有專業的測試人員，至少每 2~3 個開發人員一個測試人員，你要麼會交付缺陷產品，要麼你讓時薪 $100 的開發人員，去做時薪 $30 測試人員的工作。

我和 Joel 觀點的主要不同是，對於微軟而言，開發人員和測試人員是一樣的，開發人員的薪酬並不是測試人員的 3 倍。測試人員花費時間，遍歷程式碼變更，確保提交的修改可用，而且沒有引入新的問題，這些都與開發人員的時間一樣有價值。當然，這也算安全網。

擁有測試人員是很好的選擇，但是 Joel 提出了更好的觀點，那就是，你千萬不要浪費測試人員的價值。

開發人員需要對自己的程式碼負責。如果你不是特別確信自己的程式碼無 bug，就不應當提交。這意味著你需要進行人工測試、單元測試、整合測試等等。既然在未進行程式碼 review 之前，程式碼是不可提交的，那沒有進行測試，又怎麼可以提交呢？

測試人員不需要遍歷每一個變更，但是他們需要確保，產品作為一個整體依然是穩定的。他們應該能將他們的時間投入測試模型，這遠比開發人員更加有價值。有測試人員並不是最關鍵的，有完整有效的測試計劃才是。

更新建議：是否有完整的測試計劃。

11. 新員工面試時寫程式碼嗎？

當你在很多類似 Hacker News，或者一些  Reddit 之類開發網站搜尋關鍵字“面試”時，結果中的文章有多少對現在的面試流程是正面評價呢？非常少！每個人都很清楚，現在的面試系統很爛，我們需要更好的選擇。在某人想出更好的之前，就當現在只有這麼一個辦法，雖然看起來不像什麼好點子，我們就將就一下吧。

目前有如下一些不同的面試方法：

1. 白板面試。
2. 做一個家庭作業式的小專案。
3. 到公司來，與我們一起工作 6 個月，作為試用期。

有件事我們都有共識，開發人員應該編碼。既然這是他們的工作，那你就應該在這方面測試他們。就不要用查詢特定的語法錯誤這種問題來為難他們，也不要讓他們選擇你的團隊的工作語言了，只要確保他們可以編碼即可。

就像我們前面看到的，這一條也是非常常識的問題，我覺得就沒必要繼續保留了。

更新建議：刪除。

12. 是否進行走廊可用性測試？

這是一條鮮為人知的規則，我們看看 Joel 的定義：

走廊可用性測試是這樣的，你在走廊裡，隨手請一位路人，幫忙測試你剛剛編寫的程式碼。如果如此請了 5 個人幫忙，你就可以找到程式碼中 95% 影響可用性的問題。

現在，如果我說走廊可用性測試是個好東西，應該不會有太多人反對吧，但是對於灰色桌面背景上的灰色工具欄，上面還有灰色按鈕的情況，這就未必了。電腦使用者（如今這個定義非常寬泛）通常不是特別瞭解其工作原理。對於專業工具，你可能需要按鈕提示資訊、拖拽支援、鍵盤快捷方式等，這樣就非常棒了。然而對於 Facebook，得讓你的爺爺奶奶也能用才行。這需要清晰的設計：元素之間採用高對比度，在合理的位置進行互動，還要有適合的大小。

在各種情況下，需要建立使用者介面和使用者體驗，我所說的不僅僅是常規的 UI，而是類似“以合理的方式，控制檔案儲存操作”這樣的事，這已經不是一個開發人員能做到的了，應該由專業人員來做。現在這是專業的 UI 和 UX 設計師應該掌握的一種專業技能。

更新建議：是否有專業的 UI 和 UX 設計師?

現在我們看看「Joel 測試」變成什麼樣了：

我們砍掉了部分規則，修正了其他的。但是這還沒完。這只是我們如何修改已有規則，使之與時俱進，但是我們還需要新增一些如今非常重要的規則。

新增的 3 個規則

所有程式碼都經過 review 了嗎？

每個人都會犯錯，無論你是剛剛畢業的新人，還是身經百戰的程式設計老司機，你都會犯錯。我們總是過於依賴編譯器幫我們發現錯誤，這並不是編譯器的正確使用方法。這就是我們需要“測試”的原因。但是測試也可能失效，我們不能 100% 依賴它。對你的程式碼擦亮眼睛，能讓你發現平時未發現的東西。除此之外，這還能讓你的程式碼與團隊程式碼風格保持一致，編譯器通常不具備這樣的能力（程式碼檢查這個主題，我們換個機會再談）。一致性良好的程式碼，可以方便團隊成員閱讀、使用你的程式碼。

是否有編碼標準？

這條規則與上面一條相互依存。編寫程式碼非常重要，但是最終你需要能重讀你的程式碼。很遺憾，現實並不是這樣。所以，我們應該儘可能讓程式碼易於閱讀。首要任務就是，保證程式碼庫的一致性。通過制定一系列規範，在團隊內貫徹，令程式碼易於閱讀和理解。在程式碼庫中搜尋最常用的模組、型別等等，清晰定義期望的程式碼風格，幫助新進開發人員逐步跟上進度，這比在開發過程中一點點明確風格要好的多。也可以在持續整合系統中，增加自動程式碼檢查工具，推進這些程式碼規範。

新員工是否有培訓？

這看起來顯而易見，但事實上卻並不常見。很多新進開發人員，加入一家公司，就立刻被投入深水區。這個過程對開發人員和公司，都是浪費。有一些會試著遊起來，但是絕大多數會沉沒。當你加入一家公司後，你應當獲得工作所需的一些必要資訊。我並不是說你應該在一間會議室裡待一週，學習 HR 課程、聆聽 VP 的宣講，這確非我的本意。實際上你應該獲得你所工作系統的文件，並且，有一位團隊成員，給你當一段時間導師，以幫助你儘快跟上進度。沒錯，這意味著這個開發人員可能在培訓階段的輸出會有所減少，但是在此之後，你就獲得了兩個開發人員，任何會算數的人，都會看出來，這事一筆值當的投資。

結語

那麼，我們看看我們 2017 版 “Joel 測試”是怎樣的：

好棒耶！讓我們喜大普奔地照辦起來吧。

還是不要了！該測試不是萬金油，只是個指導意見。它是一個指導系統，而非一套完整的評估系統。一個得到滿分的企業，依然可能是一家不宜工作的地方。當然，如果一家公司連 10 分都拿不到，那這是家不靠譜的公司基本沒跑。只要確保你的僱主能獲得 11~12 這樣的高分，然後根據自己的判斷來。千萬不要迷信！