這篇文章由本人翻譯

如果你與軟件行業(yè)有若干聯(lián)系，但是還不知道Joel這個人以及他的博客，那么趕快拿起百度，然后盡可能多的了解他和他的思想，對你肯定有好處。這篇是他博客中的經(jīng)典之作，收錄在他的兩本書中：《Joel on Software》和《Smart & Gets Things Done》,這兩本書主要收錄和整理了他的博客中的經(jīng)典文章，有必要一看。 要翻譯出原作者的味道真的很難，所以我們經(jīng)常罵一些翻譯過來的中文書籍太爛，特別是由那些不懂技術(shù)的人翻譯的技術(shù)書籍。所以如果你是是程序開發(fā)人員，再次善意的提醒您：“學(xué)好英文”，這句話被很多人重復(fù)，也不多我一個了，當(dāng)然聽不聽由你。

 

 

你有沒有聽說過SEMA？這是一個非常復(fù)雜的軟件開發(fā)團隊評價體系。等等！千萬別去研究它！僅僅是理解它就將花掉你六年時間。所以我自己搞了一套軟件開發(fā)團隊評價體系，信不信由你，這套體系最大的優(yōu)點就是只需三分鐘就可掌握！你可以把省下的時間去讀醫(yī)學(xué)院了。

                               Joel 的12條測試問題

1. 你們用了源代碼管理軟件嗎？
2. 你們是否一步就能實現(xiàn)從源代碼到可發(fā)布的產(chǎn)品？
3. 你們每天都把源代碼管理系統(tǒng)的代碼做一次生成操作嗎？
4. 你們有軟件Bug管理系統(tǒng)嗎？
5. 你們在編寫新代碼前解決bug嗎?
6. 你們有沒有一個時常更新的進度計劃？

我的這套體系非常簡潔，你只需對每個問題回答“是”或者“否”就可以了，你不需要去算什么每天寫的代碼行數(shù)或者平均bug數(shù)等等，回答“是”就給你的團隊加一分。但丑話說在前面，可別用我的這套體系去衡量你的核電站管理程序是否安全。

如果你們得了１２分，那是最好，得了１１分還過得去，但如果只得了１０分或低于１０分，你們可能就有很嚴重的問題了。但是事實上大多數(shù)的軟件開發(fā)公司只能得到２到３分，而這些公司往往有很大問題，因為像微軟這樣的公司一直是保持１２分的。

當(dāng)然，以上法則并不決定成功與否的唯一因素。舉一個極端的例子：讓一個優(yōu)秀的開發(fā)團隊去開發(fā)一個沒有人需要的軟件，那么，開發(fā)出來的軟件再好也沒人會買。同樣，一幫程序天才即使一條也不符合以上標(biāo)準(zhǔn)，也能照樣搞出一個改變世界的偉大軟件。但我告訴你，如果當(dāng)其他條件都一樣的時候，只要做到以上12件事，你的團隊就能比那些沒做到的更有紀律性并有更好的產(chǎn)出。

1.你們用了源代碼管理軟件嗎？

我用過源代碼管理商品軟件，也用過免費的，比如CVS，告訴你吧，CVS挺好用（當(dāng)我寫這篇文章之后有了Subversion，它比CVS更好用）。但如果你根本就沒有用源代碼管理軟件，那你就是累死了也沒法讓你的程序員們協(xié)同工作。他們沒法知道別人做過些什么，如果出錯了也沒法恢。源代碼管理軟件的另外一個好處在于：每個程序員都把源代碼簽出來存儲在自己的機器上，很難發(fā)生丟失源代碼的事，最起碼我還沒聽說過。

2. 你們是否一步就能實現(xiàn)從源代碼到可發(fā)布的產(chǎn)品？

我的意思是：從你們最新的源碼開始到建立起能夠發(fā)布的產(chǎn)品需要多少步驟？ 一個好的團隊?wèi)?yīng)該有一個腳本可自動的實現(xiàn)這個過程：把源文件提取出來，從新編譯每一行代碼，根據(jù)各種編譯開關(guān)（#ifdef）進行編譯，得到各種版本（包括各種語言）的可執(zhí)行程序，做成安裝包，放到最終的發(fā)布媒介上，如ＣＤ光盤，直接發(fā)布到網(wǎng)站上等等。

如果這個過程不是一步做完，就有可能出差錯。當(dāng)你接近產(chǎn)品發(fā)布的時侯，你可能很急于想把最后幾個bug解決，然后盡快地發(fā)布。如果這時候你需要做２０步來編譯代碼，制作安裝包...等等，你肯定會急得要命，然后犯一些很不該犯的錯誤。

正因為這個原因，我工作的前一個公司放棄WISE而改用InstallShield：因為我們需要能夠讓W(xué)idows NT的計劃管理程序在夜間自動的啟動腳本程序來完成整個自作安裝包的過程，WISE不能被Windows NT的計劃管理程序啟動而InstallShield可以，我們只能放棄使用WISE。（WISE的那幫家伙向我保證他們的下一代產(chǎn)品一定支持在夜里自動運行)

3. 你們每天都把源代碼管理系統(tǒng)的代碼做一次生成操作嗎？

你們在用代碼管理系統(tǒng)的時候有沒有遇到過這樣的事情：一個程序員不小心簽入了有問題的源代碼導(dǎo)致無法成功生成。比如，他建立了一個新源文件，在他的機器上整個編譯得很好，但忘了把它簽入到源代碼管理系統(tǒng)。他高高興興的鎖機回家了，可是別人卻因為這沒法工作下去了，也只好郁悶地回家了。

這種造成沒法生成的情況如此糟糕卻如此常見，所以如果每天都做一次生成操作的話，就可以盡可能的避免這種事發(fā)生。在一個大的團隊里，要想保證問題及時得到糾正，最好每天下午（比如午餐時）在服務(wù)器上做一次生成操作。午餐前，每個人都盡可能地把改動的源代碼都簽入，午餐后，大家回來，如果生成成功，好！這時大家再從源代碼管理系統(tǒng)里簽出最新的源程序接著工作。如果生成失敗了，那么找一個人來負責(zé)修正它，其他人因為沒有簽出所以還可以繼續(xù)在上一個沒問題的版本上工作。

在我過去的Excel的開發(fā)團隊，我們有一條規(guī)定：誰造成生成失敗，誰就得被罰去負責(zé)這個生成過程，直到下一位造成生成失敗的人來接任他。這樣做不僅可以督促大家少犯這種造成生成失敗的錯誤，而且可以讓每個人都有機會去了解生成的過程。

4. 你們有bug管理系統(tǒng)嗎？
不論你有任何借口，只要你寫程序，哪怕只是一個人的小組，如果你沒有一個系統(tǒng)化的管理軟件bug的工具，你寫的程序的質(zhì)量一定高不了。許多程序員覺得自己可以用大腦記住發(fā)現(xiàn)的bug清單。沒門！我最多也就能記住２到３個軟bug，而且第二天早上就忘了，或者如果急著發(fā)布程序就更容易忘記。你絕對需要一個工具來管這些Bug。

軟件Bug管理系統(tǒng)有的功能很強大有的也很簡單，但至少要包含以下幾種信息：

• 記錄完整的Bug出現(xiàn)路徑
• 正常情況（無Bug）應(yīng)是怎樣
• 現(xiàn)在情況（有Bug）又是怎樣
• 誰來負責(zé)殺Bug
• 問題有沒有解決

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

5.在編寫新代碼前解決bug嗎？（即零缺陷，在寫新代碼前優(yōu)先搞定所有的已知bug，讓新代碼在零缺陷的前提下開發(fā)）

Microsoft Word的早期版本的開發(fā)過程被認為是'死亡之旅'。這個項目似乎永無止盡，這一過程中慢慢喪失了生機。整個項目開發(fā)團隊每天都日以繼夜的工作，但是這個項目卻總是延期，而且是一次又一次的延期，每一位團隊成員需要面對難以承受的壓力。一年以后，當(dāng)整個項目交付后，Microsoft獎勵整個團隊到Cancun休假。休假中，Word開發(fā)團隊坐下來非常嚴肅的在靈魂的深處回顧了自己和團隊的得失。

團隊認識到，開發(fā)的過程中，團隊的管理者始終堅持嚴格按照計劃進行工作。因為解決bug并不是正式的計劃中的一部分，所以每一位程序員都急著忙于編寫代碼，而沒有人注意代碼的質(zhì)量，得到的自然是錯誤百出的代碼。同時團隊中也沒有人試圖去修改bug, bug越來越多。這個過程就好比一個程序員需要寫出一行代碼，來計算Word中一行字的高度（字號大?。?，但是他很簡單的完成了這句代碼——return 12。但是并非每行字的高度都是12，而大量后來的代碼都調(diào)用了他的這一行代碼，可想而知有多少功能將由于這行代碼而成為bug，如果沒有及時修改，進度表就等同一個bug累計表（進度每向前一天就會有新的特性具有bug。此后，這種編寫代碼的方式被稱為'無限缺陷法'。

為了解決這一問題，讓項目回到正軌之上，微軟采用了我們稱之為'零缺陷'的方法。聽了這一措施，很多程序員都嗤之以鼻，因為他們覺得這是微軟的管理層想通過一個管理制度來消滅bug（實際上這是做不到的。）。而實際上，'零缺陷'的真正含義是指，在開發(fā)的過程中，在你決定進行新的代碼編寫前，你都必須仔細評估已有的bug。理解了‘零缺陷’的真正含義沒有哪一個程序員再會表示絲毫的不屑了。

一般來說，bug在你的代碼中停留的時間越長，修復(fù)這個bug的成本（時間或金錢）就越高。（下面就由短到長的給出不同的情景）

例如，如果只是出現(xiàn)了編譯器能夠發(fā)現(xiàn)的拼寫或者語法錯誤，解決他簡直是小菜一碟。

如果你第一次編譯和運行你新寫的程序的時候就發(fā)現(xiàn)了新寫的代碼中有bug，你就會很容易的修正它（不需要花多少時間），因為所有的代碼還清晰的停留在你的腦海中。

當(dāng)你發(fā)現(xiàn)bug可能存在于你一兩周之前寫的代碼中，你就需要一些時間去看懂原來寫的代碼，但是當(dāng)你讀這些兩周前的代碼的時候，你還能記起當(dāng)初你是如何編寫這些代碼的，所以能在一個合理的時間內(nèi)解決這個Bug。

可是，當(dāng)你試圖在一兩個月之前寫的一些代碼中去追蹤一個bug的時候，你往往已經(jīng)差不多忘記了大部分你當(dāng)初寫代碼的邏輯。所以想要找到并消滅這個bug就會困難的多。更進一步，如果你要去解決其他人代碼中的bug，而這個人此刻可能正在'Aruba'逍遙自在的享受著他的假期，你會發(fā)現(xiàn)這個過程簡直就是在搞科研：你必須慢慢的、有條理的、仔細再仔細的去尋，你肯定無法準(zhǔn)確告知找到并修復(fù)這個bug需要多少時間。

更為甚者，如果你在已經(jīng)發(fā)布的產(chǎn)品中發(fā)現(xiàn)了一個bug，那成本就大了去了。

這就是為什么需要及早消滅bug的原因，因為這樣用時最少。這樣做的另外一個原因就是，估算編寫新代碼的時間遠比估算消滅一個bug的時間要容易的多。比如，我想讓你告訴我編寫一個排序的代碼需要多長時間，你肯定能給我一個比較精確的時間。但是當(dāng)我讓你告訴我需要多久才能消滅這個bug時，你往往不能給我準(zhǔn)確的答案。因為你還不能確定是哪里的錯誤導(dǎo)致了這個bug，你有可能需要整整三天的時間才能找到這個bug，當(dāng)然，你也可以碰到2分鐘就找到這個bug的情況。

試著想一想，當(dāng)你的計劃中有大量的bug需要被消滅的時候，你的計劃是不是也就變得不可控制，或者說難以控制？但是如果你消滅了所有已經(jīng)發(fā)現(xiàn)的bug，你所需要做的就只剩下編寫新的代碼，這個時候你制定或者修正計劃就會準(zhǔn)確很多。

'零缺陷'開發(fā)方法之所以'偉大'的第三個重要的原因就是因為他能讓你更加快速和靈活的應(yīng)對不斷變化的競爭環(huán)境。有些程序員會告訴你，'零缺陷'就是要讓你的產(chǎn)品隨時能夠發(fā)布。假設(shè)，你的競爭對手想到了一個'該死的'新功能，并且想以此來吸引并'偷走'本應(yīng)該屬于你的客戶。什么是最有力的反擊？就是你馬上把這個新功能展示給客戶看！當(dāng)然想要展示功能，就需要此時你手里的程序不會不停的出現(xiàn)那些讓人'厭煩'的bugs。

6. 你們有沒有一個時常更新的進度計劃？

我們?yōu)槭裁匆鲞M度計劃？如果你寫的程序?qū)镜臉I(yè)務(wù)很重要，那么就有理由相信：知道什么時候能完成這個程序?qū)τ诠竞苤匾?。程序員懶于制定計劃這一點已是眾所周知的。他們總是對業(yè)務(wù)人員嚷嚷：“該完成的時候自然就完成了”

遺憾的是，事情遠遠沒有那么簡單。軟件公司在發(fā)布一個軟件之前需要提前做太多的事，這些事必須計劃好，比如制作演示樣例，產(chǎn)品展示會，廣告等等。所有這些都依賴于有一個產(chǎn)品開發(fā)計劃，并時常更新這計劃。

制定產(chǎn)品開發(fā)進度計劃的另一個關(guān)鍵原因在于，它能讓你提早明確哪些產(chǎn)品特性是你需要開發(fā)的，而把那些最不重要的產(chǎn)品特性放棄，否則你就可能陷入不重要特性的泥潭（也就是，無法控制產(chǎn)品開發(fā)的范圍，導(dǎo)致進度總是落后）。

 

７. 你們有沒有產(chǎn)品開發(fā)文檔？

（譯注：關(guān)于產(chǎn)品開發(fā)文檔，涵蓋的內(nèi)容很多，Joel針對這個問題有專門的文章進行闡述，包括如何既要敏捷又具備一定的規(guī)范性，做到很好的平衡，這個話題的爭論很多，在實踐中不斷改善才是硬道理。---Ailon）

寫產(chǎn)品開發(fā)文檔這個話題就像用牙線清潔牙齒（用牙線清潔牙齒能保證牙齒健康，可誰每天用牙線清潔牙齒）：每個人都同意寫產(chǎn)品開發(fā)文檔很好，但是就是沒人去做。

我不太肯定這個現(xiàn)象是怎么產(chǎn)生的，但是一個原因是程序員普遍討厭寫文檔。結(jié)果，當(dāng)一個團隊都是一些專注于解決問題的程序員的時候，他們就變得更喜歡用代碼來表達他們的解決方案，而不是文檔。他們情愿一開始就忘情的投入寫代碼中去，而不是先寫產(chǎn)品開發(fā)文檔。

在軟件設(shè)計階段，當(dāng)你發(fā)現(xiàn)問題你能很容易的修正，用幾行文字就可。但是一旦開始寫代碼了，修正問題的成本就會變得非常高，原因有兩方面：一是情感上的（人們誰愿意丟掉自己辛辛苦苦寫的代碼呢？），另一方面是時間開銷很大，所以這兩方面的原因使得人們從內(nèi)心中是不愿意去修正問題的。軟件開發(fā)如果沒有預(yù)先寫產(chǎn)品開發(fā)文檔往往就會充斥糟糕的設(shè)計，并且開發(fā)進度很難控制。比如當(dāng)初Netscape開發(fā)瀏覽器的時候，最開始的四個版本亂七八糟以至于后來管理者愚蠢的將所有代碼全部丟棄從新開發(fā)，結(jié)果所有以前犯的錯誤又從新犯了一次（這次開發(fā)的版本叫Mozilla），這一版本的開發(fā)簡直就是產(chǎn)生了一個失控的怪獸，花了好幾年時間才進入到Alpha階段。（產(chǎn)品開發(fā)的beta，Alpha等等階段）

我個人認為這個問題可以這么解決：讓那些不愿意寫文檔的程序員參加一個強化的寫作培訓(xùn)班，另外一個辦法是聘請非常聰明的程序經(jīng)理來專門寫程序開發(fā)文檔。不管采取何種辦法，你應(yīng)該遵守一個原則：“沒有軟件開發(fā)文檔別寫代碼。”

8. 程序員是否有安靜的工作環(huán)境？

給知識工作者安靜的個人空間可以提高工作效率，這一點在很多書上都提到過。那本經(jīng)典的軟件管理書《人件》對這點進行了很大篇幅的論述。

為什么安靜的環(huán)境如此重要？我們都知道當(dāng)知識工作者“沉浸”于工作的時候效率最高，也就是當(dāng)他全身心的集中精力在處理的問題上，完全忘記周圍的環(huán)境的時候效率最高，我們把這種狀態(tài)叫做“集中精力的境界”。這時候他們完全忘記了時間的流逝，由于全神貫注往往做出了一些很棒的東西。只有在這種時候才能有最有效的產(chǎn)出。作家、程序、科學(xué)家，甚至是籃球運動員都知道這種集中精力的境界意味著什么。

但是問題在于，集中精神不是那么容易。如果你非要定量描述它，那就這么說吧，一般要想進入工作效率最高的狀態(tài)，你平均需要15分鐘的“熱身”時間。有些時候，當(dāng)你已經(jīng)很疲勞，或者那天已經(jīng)做了很多創(chuàng)造性的工作的時候，你就很難再集中精神了，在那天剩下的時間里只能做些無足輕重的事了，比如瀏覽網(wǎng)頁，玩玩俄羅斯方塊什么的。

更要命的是這種集中精力的狀態(tài)很容易被打破。噪音、電話、出去午餐、去星巴克喝杯咖啡，或者同事都能打破這種狀態(tài)。對了，特別是同事很容易將你踢出這種集中精力的境界。當(dāng)有同事問你一個問題，表面看起來你只花了一分鐘時間回答他，但是實際上之后你可能需要半個小時來恢復(fù)到之前的全身心投入狀態(tài)，你的整天的工作效率都可能成問題（這點大鵬可能很有感觸，所以大家最好不要輕易打擾他，有事等中午休息時間再找他）。如果你工作的環(huán)境是一個嘈雜的大房間（就像很多咖啡廳想營造的環(huán)境），市場部的人員就在程序員旁邊大聲的與客戶打電話，程序員工作效率就成問題了，就會時不時的被打斷思路，很難進入那種全神貫注的狀態(tài)。

對于程序員來說，這點尤為困難。程序員的生產(chǎn)效率依賴于能夠在很短的時間里面理清很多細節(jié)。任何干擾都能阻礙他們想清一些細節(jié)。當(dāng)你被打斷然后繼續(xù)工作，很多細節(jié)都忘了（例如你剛剛用的局部變量名，或者忘記實現(xiàn)某個搜索算法下一步該做什么了），你不得不再從頭看你寫的代碼，這樣就極大的影響程序員的工作效率。

讓我們來算一個簡單的代數(shù)問題。 假設(shè)如果我們干擾程序員哪怕一分鐘，就會是他失去15分鐘的生產(chǎn)時間（這點已經(jīng)很理想了，現(xiàn)實恐怕還不止這么多）。現(xiàn)在有兩個程序員Jeff和Mutt，他們坐在一個開放的隔間里面，兩個人在鄰座。有一天，Mutt記不得strcpy這個函數(shù)的Unicode版本叫什么名字了，他可以花30秒自己去查書，也可以問Jeff，這只需要15秒。因為Mutt就坐在Jeff邊上，所以他就去問Jeff。結(jié)果Jeff就被打擾了，僅僅節(jié)約了Mutt15秒的時間，卻浪費了Jeff15分鐘的時間。

現(xiàn)在我們將他們安排到兩個獨立的辦公室，有墻和門隔著。現(xiàn)在當(dāng)Mutt記不得那個函數(shù)的名字的時候，他也可以自己花30秒時間去查書，或者跑去問Jeff，但是這時候就要花45秒鐘的時間，而且還得從椅子上站起來（往往很多時候為這種小問題程序員是不愿意挪窩的），所以Mutt就自己去查書了。這樣Mutt就花掉了30秒的時間，但是卻節(jié)省了Jeff15分鐘的時間。豈不妙哉！

9. 你們是否用了能買到的最好的工具？

用很低配置的電腦，就連編譯代碼這種事也很難在一瞬間完成。如果你的編譯過程需要花好幾秒的時間，趕緊去買一臺好點的電腦吧，那樣會節(jié)省你很多時間。如果編譯過程甚至需要15秒的時間，程序員就會等得很厭煩，這樣他們會在編譯期間去看一些洋蔥新聞（美國一家專業(yè)捏造假新聞的惡搞新聞媒體做的東西），有時候會被這些惡搞新聞吸引，結(jié)果損失了好幾小時的工作時間。

用一臺顯示器來調(diào)試圖形用戶界面的代碼，不說不可能也可以說是件很痛苦的事。如果你在寫圖形用戶界面的代碼，用兩個顯示器會容易的多。（譯注：這里指的是雙顯卡技術(shù)而不是買兩臺電腦，雙顯用來調(diào)試GUI代碼的確爽的多）

大部分程序員很多時候都要為一些圖標(biāo)或工具條制作位圖，大部分程序員都沒有一個好的位圖編輯工具。用微軟的畫圖板來編輯位圖簡直就是一個笑話，但是你還別說大部分程序員就是那么干的。

在我的上一個工作，系統(tǒng)管理員不斷的給我發(fā)那種自動發(fā)送的垃圾郵件：說我用了服務(wù)器過多磁盤空間，你知道嗎？有220M之多呢（譯注：Joel的文字很多充滿這種戲謔之語）。我氣憤的回答說，按照今天磁盤的價格，我用磁盤空間的這些花費比我用你們家?guī)l(wèi)生紙的錢少多了。你要知道哪怕我每次只用十秒的時間來清理我的文件夾，都會極大的降低我工作的效率。

頂級的開發(fā)團隊不會折磨他的程序員，哪怕因為使用一些不強大的工具帶來的只是很小的不爽，當(dāng)這些很小的不爽積累起來就會是程序員惱火和不開心。而不開心的程序員是不可能高效率的工作的。

總結(jié)起來，程序員是很容易被賄賂的，你只需要給他們一些很酷的，最新的東西。這比你給他們更多的薪水還管用，并且花費比你加工資要少得多。

10. 你們有軟件測試人員嗎？

如果你不能保證至少兩個到三個程序員就配備一個專職測試人員，那么你要不就發(fā)布充滿bug的產(chǎn)品，要不就要讓$100/小時的程序員來做本可以由$30/小時的測試人員來做的事情。節(jié)省測試人員的想法從經(jīng)濟學(xué)角度來看是完全錯誤的，但是很多人沒認識到這點。

11. 你在面試應(yīng)聘程序員的時候讓他們寫代碼了嗎？

當(dāng)你招聘魔術(shù)師的時候，可能不讓他給你露兩手絕活嗎？答案是顯然的。

當(dāng)你找廚師為你準(zhǔn)備婚宴的時候，你可能不品嘗一下他做的菜嗎？

是的，很多時候，程序員之所以獲得一份工作，往往是因為他有一份給人印象深刻的簡歷，或者面試官和他很談得來。或者只是被問到了一些瑣碎的問題（比如 CreateDialog() 和 DialogBox() 有什么區(qū)別？），這些都是些可以從幫助文檔里面查到的問題。然而你不應(yīng)該關(guān)心你要招聘的程序員是否能記住成千上萬個這種瑣碎的問題，你應(yīng)該關(guān)心他們是否能寫代碼。 有些時候情況更糟糕，比如問那種“AHA”問題，這種問題當(dāng)你知道答案的時候非常簡單，但是如果你不知道答案，不可能回答得上。（譯注：類似于腦筋急轉(zhuǎn)彎的問題）

請停止做以上的傻事吧，面試程序員的時后想做什么都由你，但至少要讓他們寫一些代碼。

12. 你有沒有做“走廊易用性”測試？

所謂“走廊易用性”測試是指，在走廊上找那些經(jīng)過的行人，讓他們用一下你做的東西。如果你能找到五個人用一下，你就能找到95%的可能影響易用性的問題。

好的用戶界面設(shè)計沒你想想都那么難，但是如果你想讓你的客戶喜歡并買你的產(chǎn)品，易用性卻是非常的關(guān)鍵。

對于用戶界面設(shè)計來說，如果你能把你的程序展示給幾個人來看（事實上5個到6個就足夠了），你就能很快發(fā)現(xiàn)用戶在用你的軟件的時候可能遇到的最大的麻煩。 即使你缺乏用戶界面設(shè)計技巧，只要你能強迫自己做“走廊易用性”測試，你設(shè)計的用戶界面就會好很多。