軟件開發成功12法則——Joel Spolsky

作者簡介：作者：Joel Spolsky 是紐約市一家小軟件公司Fog Creek Software 的創始人。他畢業于耶魯大學，曾在美國微軟公司、Viacom、Juno 任軟件設計師及經理。

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

（注：SEMA：Software Engineering Measurement and Analysis）

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

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

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

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

--------------------------------------------------------------------------------

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

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

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

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

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

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

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

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

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

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

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

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

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

如果想更多了解這個話題，可以讀我的另一篇文章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（人件） 把這個問題闡述得很清楚。

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

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

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

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

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

現在，我們把他們倆用墻和門隔開，讓他們倆分坐在不同的辦公室里，愚夫又想不起來什么函數名，自己查一下要花30秒；問杰夫，要 花45秒，因為他要站起來走過去問（對這幫程序員來說，這可不是件簡單的事，看看他們的體質就知道為什么了）。所以他選擇自己去查。愚夫損失了30秒鐘， 可是杰夫少損失了 15分鐘。哈哈！

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

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

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

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

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

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

10. 你們有沒有專職的軟件測試人員？
如果你的開發組里沒有專職的測試人員，或沒有足夠的測試人員（兩到三個程序員就應該配一個測試員），那你的產品就一定是毛病百出。想在測試員身上省錢，絕對是打錯了算盤。我真不明白為什么這么多人算不過來這筆帳。

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

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

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

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

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

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

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

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

--------------------------------------------------------------------------------

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

1. 用該法則來衡量你的軟件開發組，告訴我你得的分數，讓我來品頭論足。

2. 如果你是開發組的經理，用該法則來使你的組提高效率。如果你們一上來就能得12分，你就別再打擾你的程序員了，專心致志別讓公司的管理人員來煩你的程序員吧。

3. 如果你在找一份程序員工作，問問你未來的老板他能得幾分，如果分數很低，你一定要確信你進去后有足夠的權力來改變這一切，否則，最好躲遠點，不然，你在那兒會很難受的。

4. 如果你是投資者，正在決定是否向一個軟件公司投資，或者你的軟件公司正在決定是否兼并另一個軟件公司，該法則可以幫你做決定。