The Joel Test: 軟件開發成功 12 法則

http://chinese.joelonsoftware.com/Articles/TheJoelTest.html

The Joel Test: 軟件開發成功 12 法則

作者： 周思博 (Joel Spolsky)
譯： 李國華 Frank Li
編輯： 孫雯辰 Rosemary Sun
2000年8月9日

有沒有聽說過SEMA？這可是衡量一個軟件開發組好壞的很深奧的系統。別介，等一下！別按那個聯接！給你六年你也搞不清這玩意。所以我自己隨便攢了一套衡量系統，信不信由你，這系統，三分鐘就可掌握。你可以把省下的時間去讀醫學院了（譯註：美國的醫學院可是要讀死人的！）。

Joel 衡量法則

1. 你們用不用源文件管理系統？
2. 你們可以把整個系統從源碼到ＣＤ映像文件一步建成嗎？
3. 你們每天白天都把從系統源碼到ＣＤ映像做一遍嗎？
4. 你們有軟件蟲管理系統嗎？
5. 你們在寫新程序之前總是把現有程序裏已知的蟲解決嗎？
6. 你們的產品開發日程安排是否反映最新的開發進展情況？
7. 你們有沒有軟件開發的詳細說明書？
8. 你們的程序員是否工作在安靜的環境裏？
9. 你們是否使用現有市場上能買到的最好的工具？
10. 你們有沒有專職的軟件測試人員？
11. 你們招人面試時是否讓寫一段程序？
12. 你們是否隨便抓一些人來試用你們的軟件？

 

“Joel 衡量法則”好就好在你只需照着逐條回答以上問題，然後把所答爲“是”的問題算成一分，再加起來就可以了，而不需要去算什麼每天寫的程序行數或程序蟲的平均數等等。但咱醜話說在前面，可別用“Joel 衡量法則”去推算你的核電站管理程序是否可靠。

如果你們得了１２分，那是最好，得了１１分還過得去，但如果只得了１０分或低於１０分，你們可能就有很嚴重的問題了。嚴酷的現實是：大多數的軟件開發公司只能得到２到３分。這些公司如果得不到急救可就玄了，因爲像微軟這樣的公司從來就沒有低過１２分。 

當然，一個公司成功與否不僅僅只取決於以上標準。比如，讓一個管理絕佳的軟件公司去開發一個沒有人要的軟件，那開發出來的軟件也只能是沒有人要。或反過來，一幫軟件痞子以上標準一條也達不到，沒準照樣也能搞出一個改變世界的偉大軟件。但我告訴你，如果不考慮別的因素，你只要能達到以上１２條準則，你的團隊就是一個可以準時交活的紀律嚴明的好團隊。

1. 你們用不用源文件管理系統？
我用過商業化的源文件管理系統，我也用過免費的系統，比如CVS，告訴你吧，CVS挺好用。但如果你根本就沒有用源文件管理系統，那你就是累死了也沒法讓你的程序員出活：他們沒法知道別人在改動什麼源文件，寫錯了的源文件也沒法恢復。

使用源文件管理系統還有一大好處是，由於每一位程序員都把源文件從源文件管理系統裏提出來放到自己的硬盤裏，幾乎不會發生丟失源文件的事，最起碼我還沒聽說過。

2. 你們可以把整個系統從源碼到ＣＤ映像文件一步建成嗎？
這句話問的問題是：從你們最新的源碼開始到建立起能夠交出去的最後文件，你們有多少步驟要做？ 一個好的團隊應該有一個批處理程序一步便可將所有的工作做完，像把源文件提取出來，跟據不同的語言版本要求（英文版，中文版），和各種編譯開關（#ifdef）進行編譯，聯接成可執行文件，標上版本號，打包成ＣＤ映像文件或直接送到網站上去，等等等等。

如果這些步驟不是一步做完，就有可能出人爲差錯。而且當你很接近產品開發尾聲的時侯，你可能很急於把最後幾個蟲解決，然後儘快地交活。如果這時候你需要做２０步才能把最終文件製出來，你肯定會急得要命，然後犯一些很不該犯的錯誤。

正因爲這個原因，我工作的前一個公司從用WISE改用InstallShield：我們必需要讓我們的批處理程序完全自動化地，在夜裏，被NT scheduler起動把最終文件製成，WISE不能被NT scheduler啓動而InstallShield可以，我們只能把WISE扔掉。（WISE的那幫傢伙向我保證他們的下一代產品一定支持在夜裏自動運行.)

3. 你們每天白天都把從系統源碼到ＣＤ映像做一遍嗎？
你們有沒有遇到過這樣的事情：一個程序員不小心把有毛病的源碼放進源文件管理系統，結果造成最終文件沒法制成。比如，他建立了一個新源文件但忘了把它放進源文件管理系統，然後他高高興興鎖機回家了，因爲在他的機器上整個編譯得很好。可是別人卻因爲這沒法工作下去了，也只好悶悶地回家了。

這種造成最終文件沒法制成的情況很糟糕，但卻很常見。如果每天在白天就把最終文件制一遍的話，就可以讓這種事不造成太大危害。在一個大的團隊裏，要想保證有毛病的源碼及時得到糾正，最好每天下午（比如午餐時）制一下最終文件。午餐前，每個人都儘可能地把改動的源文件放到源文件管理系統裏，午餐後，大家回來，如果最終文件已經制成了，好！這時大家再從源文件管理系統裏取出最新的源文件接着幹活。如果最終文件製作出錯，出錯者馬上修正，而別人還可接着用原有的沒問題的源程序幹活。

在我以前曾幹過的微軟Excel開發組裏，我們有一條規定：誰造成最終文件製作出錯，誰就得被罰去負責監視以後的最終文件製作過程，直到下一位造成最終文件製作出錯的人來接任他。這樣做不僅可以督促大家少造成最終文件製作出錯，而且可以讓每個人都有機會去了解最終文件製作過程。

如果想更多瞭解這個話題，可以讀我的另一篇文章 Daily Builds are Your Friend.

4. 你們有軟件蟲管理系統嗎？
不論你有任何藉口，只要你寫程序，哪怕只是一個人的小組，如果你沒有一個系統化的管理軟件蟲的工具，你寫的程序的質量一定高不了。許多程序員覺得自己可以記得自己的軟件蟲。沒門！我從來記不住超過２到３個軟件蟲。而且第二天早上起牀後忙着去買這買那，好不容易記住的軟件蟲早忘掉了。你絕對需要一個系統來管住你的那些蟲。

軟件蟲管理系統功能有多有少。但最少要管理以下幾種信息：

• 如何重複軟件蟲的詳細步驟
• 正常情況（無蟲）應是怎樣
• 現在情況（有蟲）又是怎樣
• 誰來負責殺蟲
• 問題有沒有解決

如果你覺得用軟件蟲管理系統太麻煩，可以簡化一下，建立一個有以上５列的表來用就行了。

如果想更多瞭解這個話題，可以讀我的另一篇文章Painless Bug Tracking.

5. 你們在寫新程序之前總是把現有程序裏已知的蟲解決嗎？
微軟Windows Word的第一版的開發項目曾被認爲是“死亡之旅”項目。好象永遠也做不完，永遠超時。所有人瘋狂地工作，可怎麼也完成不了任務。整個項目一拖再拖，大家都覺得壓力大得受不了。最後終於做完了這個鬼項目，微軟把全組送到墨西哥的Cancun去度假，讓大家坐下來好好想想。

大家意識到由於項目經理過於強求程序員們按時交活，結果大家只能匆匆地趕活，寫出的程序毛病百出。由於項目經理的開發計劃並沒有考慮殺蟲的時間，大家只能把殺蟲的任務往後推，結果蟲越積越多。有一個程序員負責寫計算字體高度的程序，爲了圖快，居然寫一行“return 12;”了事。他指望以後的質檢人員發現這段程序有毛病後報告他再改正。項目經理的開發計劃事實上已變成一個列寫程序功能的清單，而上面列的所謂程序功能遲早都會成爲軟件蟲。在項目總結會上，我們稱這種工作方法爲“絕對劣質之路”。

爲了避免再犯這個錯誤，微軟制定了“零缺陷策略”。許多程序員嘲笑這個策略，覺得經理們似乎在指望靠行政命令來提高產品質量。而事實上“零缺陷策略”的真正含義是：在任何時候，都要把解決現有程序裏的問題作爲首要問題來抓，然後再去寫新程序。

爲什麼要這樣做呢？

一般說來，你越不及時地殺蟲，殺蟲的代價（時間和金錢）就會越高。比如，你寫程序時打錯了一個字，編譯器馬上告訴你，你很容易就把它改正。你剛寫好的程序在第一次運行時發現了一個問題，你也很快就能解決它，因爲你對你剛寫的程序還記憶猶新。如果你運行你的程序時發現了一個問題，可這個程序是幾天以前寫的，你可能就需要折騰一會兒，還好，你還大致記得，所以不會花太長時間。但如果你在你幾個月以前寫的程序裏發現了問題，就比較難解決了，因爲你已經忘了許多細節。這時候，你還沒準兒正忙着殺別人程序裏的蟲吶，因爲這傢伙到加勒比海阿魯巴島度假去了。這時候，解決這一堆問題的難度不亞於從事尖端科學研究。你一定得小心翼翼地，非常系統化地從事，而且你很難知道多長時間你才能把問題解決。還有更糟糕的，你的程序已交到用戶手裏了，才發現問題，那你就等着套腰包吧。

總結起來，就一條：越早解決問題，越容易解決。

另外還有一個原因，剛寫的程序裏發現問題，你能夠比較容易地估算解決它的時間。舉個例子，如果我問你寫一段程序去把一個列表排序需要花多長時間，你可以給我一個比較確切的估計。如果你的程序，在Internet Explorer 5.5安裝以後，工作不正常。我問你要多長時間把這個問題解決，你恐怕都估計不出來，因爲你根本就不知道是什麼原因造成了這個問題。你可能要花三天時間才能解決，也有可能只花兩分鐘。

這個例子告訴我們，如果你的開發過程中有許多蟲沒有及時解決，那你的開發計劃肯定不可靠。反過來，如果你們已經把已知的蟲全部解決了，要做的事只是寫新的程序，那你的開發計劃就會比較準確。

把已知的蟲全部解決，這樣做還有一個好處：你可以對競爭對手快速反擊。有些人把這叫着“讓開發中的產品隨時處在可以交給用戶的狀態”。如果你的競爭對手推出一個新的功能想把你的客戶搶走，你可以馬上在你的產品里加上這個功能，立刻將新產品交付用戶，因爲你沒有一大堆積累下來的問題要解決。

6. 你們的產品開發日程安排是否反映最新的開發進展情況？
爲什麼我們需要開發日程安排？如果你的程序對公司的業務很重要，那公司就必須知道你的程序何時能寫完。滿世界的程序員都有一個通病，那就是他們都搞不清自己何時才能寫完要寫的程序。他們都只會對管理人員嚷嚷：“等我做好了就做好了！”

不幸的是，程序寫完了，事遠遠沒完。作爲一個公司，在發行產品之前，還有許許多多的事情要做：何時做產品演示？何時參加展覽會？何時發廣告？等等。所有的這一且都依賴於產品的開發日程安排。

定下產品開發日程安排，還有一個很關鍵的好處：它逼着你只做叫你做的功能，甩掉那些可要可不要的功能，否則這些可要可不要的東西有可能把你纏住。請看featuritis 。

定下產品開發日程安排，按照它開發，這並不難做，請看我的另一篇文章 Painless Software Schedules ，這篇文章告訴你一種制訂產品開發日程的好方法。

7. 你們有沒有軟件開發的詳細說明書？
寫軟件開發的詳細說明書就像是繡花：人人皆知是好東西，可沒誰願意去做。 

我不知道這是爲什麼，也許是因爲多數程序員天生就不喜歡寫文章。其結果是，一個開發組裏的程序員們，寧可用程序來溝通，也不願寫文章來表達自己。他們喜歡上來就寫程序，而不是寫什麼詳細說明書。

在產品的前期設計過程中，如果你發現了一些問題，你可以輕易地在說明書裏該幾行字就行了。一旦進入了寫程序的階段，解決問題的代價就要高得多了，不僅僅是時間上的代價，而且也有感情上的代價，因爲沒人願意將自己做成的東西扔掉。所以這時候解決問題總有一些阻力。

沒有產品開發詳細說明書就開始寫程序，往往會導致程序寫的亂七八糟，而且左拖右拖不能交付使用。我覺得這就是Netscape遇到的問題。前四個版本的程序越寫越亂，以至管理人員作出一個愚蠢的決定：把以前的程序統統扔掉，重新寫。後來他們在開發Mozilla時又犯了同樣的錯誤。產品越做越亂，完全失控，花了幾年的時間才進入內部測試階段。

我最得意的理論是：如果讓程序員們接受一些寫文章的訓練如an intensive course in writing，他們就可能會改變一下不寫說明書的壞習慣，而以上所說的糟糕的例子就有可能少發生。

另一個解決問題的辦法是：僱一些能幹的項目主任，專職寫產品開發詳細說明書。

不論採用以上哪種方法，道理只有一個：在沒有產品開發詳細說明書之前，決不可寫程序。

如果想更多瞭解這個話題，可以讀我的四篇文章。

8. 你們的程序員是否工作在安靜的環境裏？
當你讓你的智囊們工作在安靜，寬敞，不受人打擾的環境裏，他們往往能更快地出活，這已是不爭的事實。有一本經典的講軟件開發管理的書Peopleware 把這個問題闡述得很清楚。

問題在於，我們都知道最好不要打斷這些智囊們的思路，讓他們一直處於他們的最佳狀態中，這樣他們就能全神貫注，廢寢忘食地工作，充分發揮他們的作用。作家，程序員，科學家，甚至籃球運動員都有他們的最佳狀態。

問題還在於，進入這個最佳狀態不容易。我覺得平均起來，需要１５分鐘才能進入最佳狀態，達到最高工作效率。有時侯，當你疲勞了或已經高效率地幹了許多工作了，你就很難再進入這個狀態，只好乾點雜事打發時間，或上網，玩遊戲等。

問題更在於，你很容易就被各種各樣的事打擾，被拽出你的最佳狀態：噪音啦，電話啦，吃午飯啦，喝杯咖啡啦，被同事打擾啦，等等。如果一個同事問你一個問題，只花你一分鐘，可你卻被拽出你的最佳工作狀態，重新回到這個狀態需要花半小時。你的工作效率因此而受到很大影響。如果讓你在一個嘈雜的大房間裏工作（那幫搞網站的傢伙還就喜歡這樣），邊上的推銷員在電話裏大叫大嚷，你就很難出活，因爲你進入不了你的最佳工作狀態。

作爲程序員，進入最佳工作狀態更難。你先要把方方面面的細節裝在腦子裏， 任何一種干擾都可能讓你忘掉其中某些東西。你重新回來工作時，發現好些東西記不起來了（如你剛用的局部變量名，或你剛纔的搜索程序寫到哪裏了等）你只好看看剛寫的程序，回憶一下，慢慢地回到你剛纔的最佳工作狀態。

我們來做一個簡單的算數。假設一個程序員被打擾一下，哪怕只有一分鐘，他卻需要花１５分鐘才能回到最佳工作狀態（統計資料顯示如此）。我們有兩個程序員：傑夫和愚夫， 坐在一個大辦公區裏工作。愚夫想不起來用什麼函數去進行Unicode 字符串複製。他可以花３０秒查一下，或者花１５秒問傑夫。由於他坐在傑夫的旁邊，他就選擇去問傑夫。傑夫被打擾了一下，耽誤了他１５分鐘，節省了愚夫１５秒鐘。

現在，我們把他們倆用牆和門隔開，讓他們倆分坐在不同的辦公室裏，愚夫又想不起來什麼涵數名，自己查一下要花３０秒；問傑夫，要花４５秒，因爲他要站起來走過去問（對這幫程序員來說，這可不是件簡單的事，看看他們的體質就知道爲什麼了）。所以他選擇自己去查。愚夫損失了３０秒鐘，可是傑夫少損失了１５分鐘。哈哈！

 9. 你們是否使用現有市場上能買到的最好的工具？
用可編譯語言寫程序恐怕是這世界上爲數不多的還不能隨便抓一個破計算機就可以做的事。如果你用於編譯的時間超過幾秒鐘，你就應該換一臺最新最快的計算機了。因爲如果編譯時間超過１５秒，程序員們就會不耐煩，轉而去上網看一些無關的東西比如The Onion，弄不好一看就是好幾個小時。

調試圖形界面軟件時，用只有一個顯示器的計算機不僅不方便，有時甚至是不可能。用有兩個顯示器的計算機，要方便許多。

程序員們經常不可避免地要去畫一些圖標或工具欄圖。多數程序員沒有一個好的圖形編輯器可用。用微軟的“畫筆”軟件去畫圖標簡直是笑話，可事實上大家還就在這樣做。

在我的前一個工作，系統管理員成天給我發來自動警告，說我在服務器上使用了超過２２０兆的空間。我告訴他，按現在硬盤的價錢，超出這點空間的價錢遠低於我用的廁紙的價錢。讓我花１０分鐘去清理我的文件絕對是我工作效率的莫大浪費。

一流的開發組絕不折騰它的程序員。工具落後會讓人用起來覺得難受，一點點積累起來，會讓程序員們成天叫苦，而一個成天叫苦的程序員絕對不會是一個高消率的程序員。

再添一句，要想使你的程序員高興，最好的辦法就是給他們買一些最新最棒的工具軟件。用這種方法可以讓他們乖乖地爲你工作，這可比用高薪吸引他們來得便宜得多。

10. 你們有沒有專職的軟件測試人員？
如果你的開發組裏沒有專職的測試人員，或沒有足夠的測試人員（兩到三個程序員就應該配一個測試員），那你的產品就一定是毛病百出，或者你在花１００美元一小時的代價去僱你的程序員去做３０美元一小時就可以僱到的測試員的工作。想在測試員身上省錢，絕對是打錯了算盤。我真不明白爲什麼這麼多人算不過來這筆帳。

我有另一篇文章專門講這個，請看Top Five (Wrong) Reasons You Don't Have Testers。

11. 你們招人面試時是否讓寫一段程序？
我問你，讓你去招一個魔術師，你是否連看都不看一眼他的魔術玩得怎樣就要他？當然不會！

你舉辦婚宴，要請一個廚師，你是不是連嚐也不嚐他做的菜好吃不好吃就要他？我想也不會。

奇怪的是，幾乎每天都有這樣的事發生：在面試一個程序員時，簡歷寫得漂亮，談得熱火朝天，問幾個簡單的問題（如CreateDialog()和DialogBox()有什麼區別？這種問題，查一下幫助文件就知道了），人就招進來了。你真正應該關心的不是這人記不記得這些寫程序的邊邊角角的東西，而是他能否出產品！更糟糕的是，許多問題是知道就知道，不知道，想死也不知道的問題。

不能這樣下去了！在面試時，請一定要讓寫一段程序。在我的這篇文章裏Guerrilla Guide to Interviewing，我有許多好建議。

12. 你們是否隨便抓一些人來試用你們的軟件？
這句話的意思是，讓你從走道里走過的人中，隨便抓幾個人來，讓他們試用你的軟件。如果你抓五個人來用你的軟件，那你就可能把你的程序中９５％的不方便使用的地方找出來。

要想讓用戶去買你的軟件，你必須要設計好你的用戶界面。這其實並不難。你可以讀我的free online book on UI design打打基礎。

用戶界面設計的關鍵是，如果你讓幾個人去用你的軟件（五六人可能就夠了），你可能很快就找出最大的問題。想知道爲什麼嗎，請讀Jakob Nielsen's article。只要你堅持隨便抓一些人來試用你的軟件，你就能將你的用戶界面設計得越來越好。

The Joel Test 軟件開發成功12法則的四個實用領域

1. 用該法則來衡量你的軟件開發組，告訴我你得的分數，讓我來品頭論足。
2. 如果你是開發組的經理，用該法則來使你的組提高效率。如果你們一上來就能得１２分，你就 別再打擾你的程序員了， 專心致志別讓公司的管理人員來煩你的程序員吧。
3. 如果你在找一份程序員工作，問問你未來的老闆他能得幾分，如果分數很低，你一定要確信你進去後有足夠的權力來改變這一切，否則，最好躲遠點，不然，你在那兒會很難受的。
4. 如果你是投資者，正在決定是否向一個軟件公司投資，或者你的軟件公司正在決定是否兼併另一個軟件公司，該法則可以幫你做決定。