軟件開發(fā)成功12法則——Joel Spolsky
作者簡介：作者：Joel Spolsky 是紐約市一家小軟件公司Fog Creek Software 的創(chuàng)始人。他畢業(yè)于耶魯大學(xué)，曾在美國微軟公司、Viacom、Juno 任軟件設(shè)計師及經(jīng)理。
“有
沒有聽說過SEMA？這可是衡量一個軟件開發(fā)組好壞的很深奧的系統(tǒng)。別動，等一下！別按那個鏈接！給你六年你也搞不清這玩意兒。所以我自己隨便攢了一套衡
量系統(tǒng)，信不信由你，這系統(tǒng)，三分鐘就可掌握。你可以把省下的時間去讀醫(yī)學(xué)院了（譯注：美國的醫(yī)學(xué)院可是要讀死人的！）。
（注：SEMA：Software Engineering Measurement and Analysis）
Joel 衡量法則：
1. 你們用不用源文件管理系統(tǒng)？
2. 你們可以把整個系統(tǒng)從源碼到CD映像文件一步建成嗎？
3. 你們每天白天都把從系統(tǒng)源碼到CD映像做一遍嗎？
4. 你們有軟件Bug管理系統(tǒng)嗎？
5. 你們在寫新程序之前總是把現(xiàn)有程序里已知的軟件Bug解決嗎？
6. 你們的產(chǎn)品開發(fā)日程安排是否反映最新的開發(fā)進(jìn)展情況？
7. 你們有沒有軟件開發(fā)的詳細(xì)說明書？
8. 你們的程序員是否工作在安靜的環(huán)境里？
9. 你們是否使用現(xiàn)有市場上能買到的最好的工具？
10. 你們有沒有專職的軟件測試人員？
11. 你們招人面試時是否讓寫一段程序？
12. 你們是否隨便抓一些人來試用你們的軟件？
“Joel 衡量法則”好就好在你只需照著逐條回答以上問題，然后把所答為”是”的問題算成一分，再加起來就可以了，而不需要去算什么每天寫的程序行數(shù)或程序蟲的平均數(shù)等等。但咱丑話說在前面，可別用”Joel 衡量法則”去推算你的核電站管理程序是否可靠。
如果你們得了12分，那是最好，得了11分還過得去，但如果只得了10分或低于10分，你們可能就有很嚴(yán)重的問題了。嚴(yán)酷的現(xiàn)實(shí)是：大多數(shù)的軟件開發(fā)公司只能得到2到3分。這些公司如果得不到急救可就玄了，因?yàn)橄裎④涍@樣的公司從來就沒有低過12分。
當(dāng)
然，一個公司成功與否不僅僅只取決于以上標(biāo)準(zhǔn)。比如，讓一個管理絕佳的軟件公司去開發(fā)一個沒有人要的軟件，那開發(fā)出來的軟件也只能是沒有人要。或反過來，
一幫軟件痞子以上標(biāo)準(zhǔn)一條也達(dá)不到，沒準(zhǔn)照樣也能搞出一個改變世界的偉大軟件。但我告訴你，如果不考慮別的因素，你只要能達(dá)到以上12條準(zhǔn)則，你的團(tuán)隊(duì)就
是一個可以準(zhǔn)時交活的紀(jì)律嚴(yán)明的好團(tuán)隊(duì)。”
--------------------------------------------------------------------------------
1. 你們用不用源文件管理系統(tǒng)？
我用過商業(yè)化的源文件管理系統(tǒng)，我也用過免費(fèi)的系統(tǒng)，比如CVS，告訴你吧，CVS挺好用。但如果你根本就沒有用源文件管理系統(tǒng)，那你就是累死了也沒法讓你的程序員出活：他們沒法知道別人在改動什么源文件，寫錯了的源文件也沒法恢復(fù)。
使用源文件管理系統(tǒng)還有一大好處是，由于每一位程序員都把源文件從源文件管理系統(tǒng)里提出來放到自己的硬盤里，幾乎不會發(fā)生丟失源文件的事，最起碼我還沒聽說過。
2. 你們可以把整個系統(tǒng)從源碼到CD映像文件一步建成嗎？
這
句話問的問題是：從你們最新的源碼開始到建立起能夠交出去的最后文件，你們有多少步驟要做？一個好的團(tuán)隊(duì)?wèi)?yīng)該有一個批處理程序一步便可將所有的工作做完，
像把源文件提取出來，跟據(jù)不同的語言版本要求（英文版，中文版），和各種編譯開關(guān)（#ifdef）進(jìn)行編譯，聯(lián)接成可執(zhí)行文件，標(biāo)上版本號，打包成CD映
像文件或直接送到網(wǎng)站上去，等等等等。
如果這些步驟不是一步做完，就有可能出人為差錯。而且當(dāng)你很接近產(chǎn)品開發(fā)尾聲的時侯，你可能很急于把最后幾個蟲解決，然后盡快地交活。如果這時候你需要做20步才能把最終文件制出來，你肯定會急得要命，然后犯一些很不該犯的錯誤。
正
因?yàn)檫@個原因，我工作的前一個公司從用WISE改用InstallShield：我們必需要讓我們的批處理程序完全自動化地，在夜里，被NT
scheduler起動把最終文件制成，WISE不能被NT
scheduler啟動而InstallShield可以，我們只能把WISE扔掉。（WISE的那幫家伙向我保證他們的下一代產(chǎn)品一定支持在夜里自動運(yùn)
行)
3. 你們每天白天都把從系統(tǒng)源碼到CD映像做一遍嗎？
你們有沒有遇到過這樣的事情：一個程序員不小心把有毛病的源碼放進(jìn)
源文件管理系統(tǒng)，結(jié)果造成最終文件沒法制成。比如，他建立了一個新源文件但忘了把它放進(jìn)源文件管理系統(tǒng)，然后他高高興興鎖機(jī)回家了，因?yàn)樵谒臋C(jī)器上整個
編譯得很好。可是別人卻因?yàn)檫@沒法工作下去了，也只好悶悶地回家了。
這種造成最終文件沒法制成的情況很糟糕，但卻很常見。如果每天在白
天就把最終文件制一遍的話，就可以讓這種事不造成太大危害。在一個大的團(tuán)隊(duì)里，要想保證有毛病的源碼及時得到糾正，最好每天下午（比如午餐時）制一下最終
文件。午餐前，每個人都盡可能地把改動的源文件放到源文件管理系統(tǒng)里，午餐后，大家回來，如果最終文件已經(jīng)制成了，好！這時大家再從源文件管理系統(tǒng)里取出
最新的源文件接著干活。如果最終文件制作出錯，出錯者馬上修正，而別人還可接著用原有的沒問題的源程序干活。
在我以前曾干過的微軟
Excel開發(fā)組里，我們有一條規(guī)定：誰造成最終文件制作出錯，誰就得被罰去負(fù)責(zé)監(jiān)視以后的最終文件制作過程，直到下一位造成最終文件制作出錯的人來接任
他。這樣做不僅可以督促大家少造成最終文件制作出錯，而且可以讓每個人都有機(jī)會去了解最終文件制作過程。
如果想更多了解這個話題，可以讀我的另一篇文章 Daily Builds are Your Friend.
4. 你們有軟件蟲管理系統(tǒng)嗎？
不
論你有任何借口，只要你寫程序，哪怕只是一個人的小組，如果你沒有一個系統(tǒng)化的管理軟件蟲的工具，你寫的程序的質(zhì)量一定高不了。許多程序員覺得自己可以記
得自己的軟件蟲。沒門！我從來記不住超過２到３個軟件蟲。而且第二天早上起床后忙著去買這買那，好不容易記住的軟件蟲早忘掉了。你絕對需要一個系統(tǒng)來管住
你的那些蟲。
軟件蟲管理系統(tǒng)功能有多有少。但最少要管理以下幾種信息：
如何重復(fù)軟件蟲的詳細(xì)步驟
正常情況（無蟲）應(yīng)是怎樣
現(xiàn)在情況（有蟲）又是怎樣
誰來負(fù)責(zé)殺蟲
問題有沒有解決
如果你覺得用軟件蟲管理系統(tǒng)太麻煩，可以簡化一下，建立一個有以上5列的表來用就行了。
如果想更多了解這個話題，可以讀我的另一篇文章Painless Bug Tracking.
5. 你們在寫新程序之前總是把現(xiàn)有程序里已知的蟲解決嗎？
微
軟Windows
Word的第一版的開發(fā)項(xiàng)目曾被認(rèn)為是“死亡之旅”項(xiàng)目。好象永遠(yuǎn)也做不完，永遠(yuǎn)超時。所有人瘋狂地工作，可怎么也完成不了任務(wù)。整個項(xiàng)目一拖再拖，大家
都覺得壓力大得受不了。最后終于做完了這個鬼項(xiàng)目，微軟把全組送到墨西哥的Cancun去度假，讓大家坐下來好好想想。
大家意識到由于
項(xiàng)目經(jīng)理過于強(qiáng)求程序員們按時交活，結(jié)果大家只能匆匆地趕活，寫出的程序毛病百出。由于項(xiàng)目經(jīng)理的開發(fā)計劃并沒有考慮殺蟲的時間，大家只能把殺蟲的任務(wù)往
后推，結(jié)果蟲越積越多。有一個程序員負(fù)責(zé)寫計算字體高度的程序，為了圖快，居然寫一行”return
12;”了事。他指望以后的質(zhì)檢人員發(fā)現(xiàn)這段程序有毛病后報告他再改正。項(xiàng)目經(jīng)理的開發(fā)計劃事實(shí)上已變成一個列寫程序功能的清單，而上面列的所謂程序功能
遲早都會成為軟件蟲。在項(xiàng)目總結(jié)會上，我們稱這種工作方法為“絕對劣質(zhì)之路”。
為了避免再犯這個錯誤，微軟制定了“零缺陷策略”。許多程序員嘲笑這個策略，覺得經(jīng)理們似乎在指望靠行政命令來提高產(chǎn)品質(zhì)量。而事實(shí)上“零缺陷策略”的真正含義是：在任何時候，都要把解決現(xiàn)有程序里的問題作為首要問題來抓，然后再去寫新程序。
為什么要這樣做呢？
一
般說來，你越不及時地殺蟲，殺蟲的代價（時間和金錢）就會越高。比如，你寫程序時打錯了一個字，編譯器馬上告訴你，你很容易就把它改正。你剛寫好的程序在
第一次運(yùn)行時發(fā)現(xiàn)了一個問題，你也很快就能解決它，因?yàn)槟銓δ銊倢懙某绦蜻€記憶猶新。如果你運(yùn)行你的程序時發(fā)現(xiàn)了一個問題，可這個程序是幾天以前寫的，你
可能就需要折騰一會兒，還好，你還大致記得，所以不會花太長時間。但如果你在你幾個月以前寫的程序里發(fā)現(xiàn)了問題，就比較難解決了，因?yàn)槟阋呀?jīng)忘了許多細(xì)
節(jié)。這時候，你還沒準(zhǔn)兒正忙著殺別人程序里的蟲吶，因?yàn)檫@家伙到加勒比海阿魯巴島度假去了。這時候，解決這一堆問題的難度不亞于從事尖端科學(xué)研究。你一定
得小心翼翼地，非常系統(tǒng)化地從事，而且你很難知道多長時間你才能把問題解決。還有更糟糕的，你的程序已交到用戶手里了，才發(fā)現(xiàn)問題，那你就等著掏腰包吧。
總結(jié)起來，就一條：越早解決問題，越容易解決。
另外還有一個原因，剛寫的程序里發(fā)現(xiàn)問題，你能夠比較容易地估算解決它的時
間。舉個例子，如果我問你寫一段程序去把一個列表排序需要花多長時間，你可以給我一個比較確切的估計。如果你的程序，在Internet
Explorer
5.5安裝以后，工作不正常。我問你要多長時間把這個問題解決，你恐怕都估計不出來，因?yàn)槟愀揪筒恢朗鞘裁丛蛟斐闪诉@個問題。你可能要花三天時間才
能解決，也有可能只花兩分鐘。
這個例子告訴我們，如果你的開發(fā)過程中有許多蟲沒有及時解決，那你的開發(fā)計劃肯定不可靠。反過來，如果你們已經(jīng)把已知的蟲全部解決了，要做的事只是寫新的程序，那你的開發(fā)計劃就會比較準(zhǔn)確。
把
已知的蟲全部解決，這樣做還有一個好處：你可以對競爭對手快速反擊。有些人把這叫著“讓開發(fā)中的產(chǎn)品隨時處在可以交給用戶的狀態(tài)”。如果你的競爭對手推出
一個新的功能想把你的客戶搶走，你可以馬上在你的產(chǎn)品里加上這個功能，立刻將新產(chǎn)品交付用戶，因?yàn)槟銢]有一大堆積累下來的問題要解決。
6. 你們的產(chǎn)品開發(fā)日程安排是否反映最新的開發(fā)進(jìn)展情況？
為什么我們需要開發(fā)日程安排？如果你的程序?qū)镜臉I(yè)務(wù)很重要，那公司就必須知道你的程序何時能寫完。滿世界的程序員都有一個通病，那就是他們都搞不清自己何時才能寫完要寫的程序。他們都只會對管理人員嚷嚷：“等我做好了就做好了！”
不幸的是，程序?qū)懲炅耍逻h(yuǎn)遠(yuǎn)沒完。作為一個公司，在發(fā)行產(chǎn)品之前，還有許許多多的事情要做：何時做產(chǎn)品演示？何時參加展覽會？何時發(fā)廣告？等等。所有的這一且都依賴于產(chǎn)品的開發(fā)日程安排。
定下產(chǎn)品開發(fā)日程安排，還有一個很關(guān)鍵的好處：它逼著你只做叫你做的功能，甩掉那些可要可不要的功能，否則這些可要可不要的東西有可能把你纏住。請看featuritis 。
定下產(chǎn)品開發(fā)日程安排，按照它開發(fā)，這并不難做，請看我的另一篇文章 Painless Software Schedules ，這篇文章告訴你一種制訂產(chǎn)品開發(fā)日程的好方法。
7. 你們有沒有軟件開發(fā)的詳細(xì)說明書？
寫軟件開發(fā)的詳細(xì)說明書就像是繡花：人人皆知是好東西，可沒誰愿意去做。
我不知道這是為什么，也許是因?yàn)槎鄶?shù)程序員天生就不喜歡寫文章。其結(jié)果是，一個開發(fā)組里的程序員們，寧可用程序來溝通，也不愿寫文章來表達(dá)自己。他們喜歡上來就寫程序，而不是寫什么詳細(xì)說明書。
在產(chǎn)品的前期設(shè)計過程中，如果你發(fā)現(xiàn)了一些問題，你可以輕易地在說明書里該幾行字就行了。一旦進(jìn)入了寫程序的階段，解決問題的代價就要高得多了，不僅僅是時間上的代價，而且也有感情上的代價，因?yàn)闆]人愿意將自己做成的東西扔掉。所以這時候解決問題總有一些阻力。
沒
有產(chǎn)品開發(fā)詳細(xì)說明書就開始寫程序，往往會導(dǎo)致程序?qū)懙膩y七八糟，而且左拖右拖不能交付使用。我覺得這就是Netscape遇到的問題。前四個版本的程序
越寫越亂，以至管理人員作出一個愚蠢的決定：把以前的程序統(tǒng)統(tǒng)扔掉，重新寫。后來他們在開發(fā)Mozilla時又犯了同樣的錯誤。產(chǎn)品越做越亂，完全失控，
花了幾年的時間才進(jìn)入內(nèi)部測試階段。
我最得意的理論是：如果讓程序員們接受一些寫文章的訓(xùn)練，如an intensive course in writing，他們就可能會改變一下不寫說明書的壞習(xí)慣，而以上所說的糟糕的例子就有可能少發(fā)生。
另一個解決問題的辦法是：雇一些能干的項(xiàng)目主任，專職寫產(chǎn)品開發(fā)詳細(xì)說明書。
不論采用以上哪種方法，道理只有一個：在沒有產(chǎn)品開發(fā)詳細(xì)說明書之前，決不可寫程序。
如果想更多了解這個話題，可以讀我的四篇文章。
8. 你們的程序員是否工作在安靜的環(huán)境里？
當(dāng)你讓你的智囊們工作在安靜，寬敞，不受人打擾的環(huán)境里，他們往往能更快地出活，這已是不爭的事實(shí)。有一本經(jīng)典的講軟件開發(fā)管理的書Peopleware（人件） 把這個問題闡述得很清楚。
問題在于，我們都知道最好不要打斷這些智囊們的思路，讓他們一直處于他們的最佳狀態(tài)中，這樣他們就能全神貫注，廢寢忘食地工作，充分發(fā)揮他們的作用。作家，程序員，科學(xué)家，甚至籃球運(yùn)動員都有他們的最佳狀態(tài)。
問題還在于，進(jìn)入這個最佳狀態(tài)不容易。我覺得平均起來，需要15分鐘才能進(jìn)入最佳狀態(tài)，達(dá)到最高工作效率。有時侯，當(dāng)你疲勞了或已經(jīng)高效率地干了許多工作了，你就很難再進(jìn)入這個狀態(tài)，只好干點(diǎn)雜事打發(fā)時間，或上網(wǎng)，玩游戲等。
問
題更在于，你很容易就被各種各樣的事打擾，被拽出你的最佳狀態(tài)：噪音啦，電話啦，吃午飯啦，喝杯咖啡啦，被同事打擾啦，等等。如果一個同事問你一個問題，
只花你一分鐘，可你卻被拽出你的最佳工作狀態(tài)，重新回到這個狀態(tài)需要花半小時。你的工作效率因此而受到很大影響。如果讓你在一個嘈雜的大房間里工作（那幫
搞網(wǎng)站的家伙還就喜歡這樣），邊上的推銷員在電話里大叫大嚷，你就很難出活，因?yàn)槟氵M(jìn)入不了你的最佳工作狀態(tài)。
作為程序員，進(jìn)入最佳工
作狀態(tài)更難。你先要把方方面面的細(xì)節(jié)裝在腦子里，任何一種干擾都可能讓你忘掉其中某些東西。你重新回來工作時，發(fā)現(xiàn)好些東西記不起來了（如你剛用的局部變
量名，或你剛才的搜索程序?qū)懙侥睦锪说龋阒缓每纯磩倢懙某绦颍貞浺幌拢鼗氐侥銊偛诺淖罴压ぷ鳡顟B(tài)。
我們來做一個簡單的算
數(shù)。假設(shè)一個程序員被打擾一下，哪怕只有一分鐘，他卻需要花15分鐘才能回到最佳工作狀態(tài)（統(tǒng)計資料顯示如此）。我們有兩個程序員：杰夫和愚夫，
坐在一個大辦公區(qū)里工作。愚夫想不起來用什么函數(shù)去進(jìn)行Unicode
字符串復(fù)制。他可以花30秒查一下，或者花15秒問杰夫。由于他坐在杰夫的旁邊，他就選擇去問杰夫。杰夫被打擾了一下，耽誤了他15分鐘，節(jié)省了愚夫15
秒鐘。
現(xiàn)在，我們把他們倆用墻和門隔開，讓他們倆分坐在不同的辦公室里，愚夫又想不起來什么函數(shù)名，自己查一下要花30秒；問杰夫，要
花45秒，因?yàn)樗酒饋碜哌^去問（對這幫程序員來說，這可不是件簡單的事，看看他們的體質(zhì)就知道為什么了）。所以他選擇自己去查。愚夫損失了30秒鐘，
可是杰夫少損失了 15分鐘。哈哈！
9. 你們是否使用現(xiàn)有市場上能買到的最好的工具？
用可編譯語言寫程序恐怕是這世界上為數(shù)
不多的還不能隨便抓一個破計算機(jī)就可以做的事。如果你用于編譯的時間超過幾秒鐘，你就應(yīng)該換一臺最新最快的計算機(jī)了。因?yàn)槿绻幾g時間超過15秒，程序員
們就會不耐煩，轉(zhuǎn)而去上網(wǎng)看一些無關(guān)的東西比如 The Onion，弄不好一看就是好幾個小時。
調(diào)試圖形界面軟件時，用只有一個顯示器的計算機(jī)不僅不方便，有時甚至是不可能。用有兩個顯示器的計算機(jī)，要方便許多。
程序員們經(jīng)常不可避免地要去畫一些圖標(biāo)或工具欄圖。多數(shù)程序員沒有一個好的圖形編輯器可用。用微軟的“畫筆”軟件去畫圖標(biāo)簡直是笑話，可事實(shí)上大家還就在這樣做。
在我的前一個工作，系統(tǒng)管理員成天給我發(fā)來自動警告，說我在服務(wù)器上使用了超過220兆的空間。我告訴他，按現(xiàn)在硬盤的價錢，超出這點(diǎn)空間的價錢遠(yuǎn)低于我用的廁紙的價錢。讓我花10分鐘去清理我的文件絕對是我工作效率的莫大浪費(fèi)。
一流的開發(fā)組絕不折騰它的程序員。工具落后會讓人用起來覺得難受，一點(diǎn)點(diǎn)積累起來，會讓程序員們成天叫苦，而一個成天叫苦的程序員絕對不會是一個高消率的程序員。
再添一句，要想使你的程序員高興，最好的辦法就是給他們買一些最新最棒的工具軟件。用這種方法可以讓他們乖乖地為你工作，這可比用高薪吸引他們來得便宜得多。
10. 你們有沒有專職的軟件測試人員？
如果你的開發(fā)組里沒有專職的測試人員，或沒有足夠的測試人員（兩到三個程序員就應(yīng)該配一個測試員），那你的產(chǎn)品就一定是毛病百出。想在測試員身上省錢，絕對是打錯了算盤。我真不明白為什么這么多人算不過來這筆帳。
我有另一篇文章專門講這個，請看Top Five (Wrong) Reasons You Don't Have Testers。
11. 你們招人面試時是否讓寫一段程序？
我問你，讓你去招一個魔術(shù)師，你是否連看都不看一眼他的魔術(shù)玩得怎樣就要他？當(dāng)然不會！
你舉辦婚宴，要請一個廚師，你是不是連嚐也不嚐他做的菜好吃不好吃就要他？我想也不會。
奇
怪的是，幾乎每天都有這樣的事發(fā)生：在面試一個程序員時，簡歷寫得漂亮，談得熱火朝天，問幾個簡單的問題（如CreateDialog()和
DialogBox()有什么區(qū)別？這種問題，查一下幫助文件就知道了），人就招進(jìn)來了。你真正應(yīng)該關(guān)心的不是這人記不記得這些寫程序的邊邊角角的東西，
而是他能否出產(chǎn)品！更糟糕的是，許多問題是知道就知道，不知道，想死也不知道的問題。
不能這樣下去了！在面試時，請一定要讓寫一段程序。在我的這篇文章里Guerrilla Guide to Interviewing，我有許多好建議。
12. 你們是否隨便抓一些人來試用你們的軟件？
這句話的意思是，讓你從走道里走過的人中，隨便抓幾個人來，讓他們試用你的軟件。如果你抓五個人來用你的軟件，那你就可能把你的程序中95%的不方便使用的地方找出來。
要想讓用戶去買你的軟件，你必須要設(shè)計好你的用戶界面。這其實(shí)并不難。你可以讀我的free online book on UI design打打基礎(chǔ)。
用戶界面設(shè)計的關(guān)鍵是，如果你讓幾個人去用你的軟件（五六人可能就夠了），你可能很快就找出最大的問題。想知道為什么嗎，請讀Jakob Nielsen's article。只要你堅(jiān)持隨便抓一些人來試用你的軟件，你就能將你的用戶界面設(shè)計得越來越好。
--------------------------------------------------------------------------------
The Joel Test 軟件開發(fā)成功12法則的四個實(shí)用領(lǐng)域：
1. 用該法則來衡量你的軟件開發(fā)組，告訴我你得的分?jǐn)?shù)，讓我來品頭論足。
2. 如果你是開發(fā)組的經(jīng)理，用該法則來使你的組提高效率。如果你們一上來就能得12分，你就別再打擾你的程序員了，專心致志別讓公司的管理人員來煩你的程序員吧。
3. 如果你在找一份程序員工作，問問你未來的老板他能得幾分，如果分?jǐn)?shù)很低，你一定要確信你進(jìn)去后有足夠的權(quán)力來改變這一切，否則，最好躲遠(yuǎn)點(diǎn)，不然，你在那兒會很難受的。
4. 如果你是投資者，正在決定是否向一個軟件公司投資，或者你的軟件公司正在決定是否兼并另一個軟件公司，該法則可以幫你做決定。