Joel測試
1.你使用原始碼管理麼？
2.你能在一步之內編譯程式麼？
3.你每天都編譯程式碼麼？
4.你有bug資料庫麼？
5.你在寫新程式碼前會修復bug麼？
6.你有最新的日程安排麼？
7.你寫程式碼有規範麼？
8.程式設計師有安靜的工作環境麼？
9.你使用錢能買到的最棒的工具麼？
10.你有測試人員麼？
11.來找工作的人在他們面試的時候會寫程式碼麼？
12.你會做走廊可用性測試麼？
Joel測試的好處是很容易快速得出針對每一個問題的“是”或“不是”。你不必去翻出那些每日程式設計行數和每個拐點的平均bug數。如果你的團隊有一個“是”就得一分。關於Joel測試令人失望的是，你真的不應該用它來確保你的核電站軟體的安全。
獲得12分是完美的，11分也還可以容忍，但10分或更低的分數表明你有嚴重的問題。事實上，大多數軟體企業都以2分或3分的分數在運轉著，他們真的很需要幫助，因為像微軟這樣的公司一直以來都以12分的完美表現在運轉。
當然，這些都不是決定成敗的唯一因素：特別是當你有一個正在開發沒人要的產品的偉大的軟體團隊的時候，那麼，人們是真的不會接受這個產品的。同時一個沒有這麼做的“神槍手”仍然能產生出令人難以置信的改變世界的軟體也是可能存在的。但是，在其他條件相同的情況下，如果你把這12件事情都做好了，你就會擁有一個能始終如一完成任務的團隊。
1.你使用原始碼管理麼？
我用過商業原始碼管理包，也用過CVS，它是免費的，讓我來告訴你，CVS很好用。但如果你沒有對原始碼進行管理，你就要應激嘗試把程式設計師都弄到一塊來工作。程式設計師根本不會知道別人都做了什麼。犯過的錯誤不能輕易改過來。關於原始碼管理系統的另一個好處就是原始碼本身可以在每個程式設計師的硬碟上進行驗證---我還從沒聽說過哪個使用原始碼管理的專案丟失了很多程式碼。
2.你能在一步之內編譯程式麼？
通過這條測試我想明白：從最新的原始碼的快速複製到進行能輸出的編譯需要多少步驟？再優秀的團隊裡，有一個單獨的指令碼，它能從零開始對程式碼做一個全面的檢查，重新編譯每一行程式碼，生成EXE檔案，在他們各種各樣的版本、程式語言和#ifdef巨集定義組合，建立安裝包和最終媒體--CDROM佈局、下載網站等等。
如果這個過程需要一個以上的步驟，就很容易出現誤差。當你接近完工的時候，你很想有很快的修復“最後一個”bug的週期，生成最後的EXE檔案等。如果編譯程式碼要用20步才能完成，執行安裝編譯器，……，等等，你會抓狂的，並且會導致你犯下愚蠢的錯誤。
正式由於這個原因，我曾工作過的上個公司就從“聰敏”模式切換到了“軟體安裝打包”模式：我們要求安裝過程中可以執行，使用NT排程從指令碼整晚自動地執行，“聰明”模式做不到這些，所以我們就拋棄了這個模式。
3.你每天都編譯程式碼麼？
當你使用原始碼管理的時候，有時候程式設計師偶然會檢查出會停止編譯的東西。比如，他們新增了一個原始檔，一切在他們的機器上編譯起來都很好，但他們忘記把原始檔新增到程式碼庫裡了。所以他們鎖定了機器就回家去了，比較健忘也比較高興。但其他人都不能繼續工作了，所以他們也不得不很不愉快地捲鋪蓋回家了。
打斷編譯是很糟糕的（也很常見的），但它能幫助程式設計師每天都編譯程式碼，以確保不會出現沒有預兆的編譯中斷。在大型團隊裡面，一個很好的確保中斷能迅速修復的方法是每天下午都對程式碼進行編譯，比如可以在午飯時間做這個。每個人都儘可能多地在午飯前做程式碼檢查。這樣當他們吃完午飯回來的時候，這個編譯就已經完成了。如果它能用，就太好了！每個人都對最新的原始碼進行檢查，然後才繼續工作。如果編譯失敗了，你就修復它，但每個人還能在預編譯、沒有中斷版本的原始碼上繼續工作。
在Excel專案組，我們有一條規則：誰中斷了編譯，作為對他的“懲罰”，他就要在其他人中斷編譯之前臨時照顧程式碼編譯的工作。這是一個很好的不中斷編譯的激勵方式，也是一個讓每個人輪流參與編譯工作從而都能知道編譯原理的好方法。
4.你有bug資料庫麼？
我不在乎你怎麼說。如果你在開發程式碼，即使是在一個人的團隊，沒有一個組織的列出程式碼裡所有已知bug的資料庫，你將會產生出低質量程式碼。許多程式設計師都認為他們能把眾多的bud存在腦子裡。真是胡說八道。我根本就不能再同一時間記住兩個或三個bug，第二天早上，或者在寫程式碼的高峰時期，就記不起它們了。你絕對要正式地跟蹤bug。
但資料庫可以是複雜或簡單的。一個最小限度的bug資料庫必須包含以下對每個bug的資料：
再次出現這個bug的完整步驟
預期的行為
觀察到的行為
它是被設計來幹嘛的
它是否已被修復
如果bug跟蹤軟體的複雜性是讓你不想跟蹤你的bug的唯一理由，只用上面包含簡單的5個元素的表格用在這些至關重要的領域，開始使用它吧。
5.你在寫新程式碼前會修復bug麼？
第一個版本的Windows系統上的微軟Word被認為是一個“死亡行軍”專案。不知道這專案要什麼時候才能完成，它不斷的延期。整個專案組在荒謬的時間裡工作著，專案再次、再次、再次延期，這時候的壓力的令人難以置信的。當討厭的事情最終出貨，幾年以後，微軟把這整個團隊都送到坎昆去度假了，他們可以靜下來做些嚴重的自我反省了。
他們意識到，專案經理一直在堅持按照“日程安排”部署工作，而程式設計師們只是頭腦簡單的趕緊完成敲程式碼的過程，又因為修復bug階段並沒有成為正式日程安排的一部分，這導致他們寫出了及其惡劣的程式碼。沒有能試圖保持住bug不發作的倒數計時。恰恰相反，據說一個程式設計師寫了計算文字行高的程式碼，僅僅寫了“renturn 12;”然後就開始等待關於他的功能總是正確的bug報導。日程安排僅僅是即將變為bug的功能的檢查清單。事後，這個被稱為“無窮大缺陷的方法”。
為了解決這個問題，微軟普遍地採取了一種叫做“零缺陷方法”的東西。公司的許多程式設計師都咯咯地笑，因為它聽起來是一種好像通過行政法令就能夠減少bug數量的管理思想。其實，“零缺陷”意味著在任意給定的時間內，優先順序最高的是消除bug，然後才是編寫新程式碼。讓我來講講為什麼。
一般情況下，你等待修復bug的時間越長，這個bug就需要付出的代價就越大（在實踐和金錢上）。
比如，當你犯了一個編譯器能捕捉的拼寫或語法錯誤時，修復它的代價微不足道。
當你第一時間看到你嘗試執行的程式碼裡有bug的時候，你能夠很快的把它解決掉，因為所以的程式碼在你腦子裡印象還很清楚。
如果你在幾天前的程式碼裡發現了bug，你會花費一段時間來找到它，但當你重讀先前寫下的程式碼後，你就會記起一切然後就能在一個合理的時間內修復這個bug。
但如果你在幾個月前的程式碼裡發現了bug，你很可能把關於這段程式碼的大部分東西都忘了，要修復它就很難了。這個時候你可能正在修復別人程式碼裡的bug，他們可能會在阿魯巴島度假，這種情況下，修復bug就像科學一樣：你不得不放緩步調、有條不紊、細緻地開始工作，並且你還不能確定需要多長時間才能找到問題的治療方法。
如果你在已經售出的程式碼中發現了bug，你會招致令人難以置信的代價修復它。
這是要立刻修復bug的一個原因：因為這樣花費更少的時間。這關係到寫新程式碼之前而不是修復bug之前還要等多長時間。比如，如果我要你預測寫一個給列表排序的代買要多長時間，你可以給我一個很好的估計值。但如果我要你預測修復一個安裝Explorer 5.5版本後程式碼就不能工作的bug需要多長時間，你猜都猜不出來，因為根本不知道到底什麼導致了這個bug。它可能需要3天時間才能跟蹤到，或者僅僅3分鐘就足夠了。
這句話的意思是，如果你有一個很多bug有待修復的日程安排，這個日程是不靠譜的。但如果你修復了所有已知的bug，並且所有剩下的都是新程式碼，這樣你的日程安排才會更加驚人的精確。
關於把bug控制到零還有另一件重要的事，那就是你可以對競爭響應更快。一些程式設計師認為這點能讓產品在任何時候為發售準備好。如果你的競爭對手從你的客戶那裡引入了一個殺手級的新功能，你就能在發售之前只實現這個功能，而不必去修復大量累計下來的bug。
6.你有最新的日程安排麼？
這條測試把我們帶到了日程安排上來。如果你的程式碼對生意是很重要的，會有很多知道程式碼完成日期怎麼對生意很重要的原因。程式設計師在制定日程安排上是出了名的倔。“該完成的時候就完成了！”他們會這樣對商務人士尖叫。
不幸的是，這並沒有讓一切變得更好。在發售程式碼之前，公司需要做太多的計劃好的決定：軟體演示，展會，廣告等。而要做到這一點的唯一方法就是擁有一個日程安排，並保證其為最新版本。
關於要有一個日程安排的另一個至關重要的原因是，它能強迫你決定要做哪些功能，然後迫使你挑選出最無關緊要的功能並砍掉它們，而不是陷入長期的猶豫中去。
同時，跟隨日程安排做事並不一定要很苛刻。
原文：http://www.joelonsoftware.com/articles/fog0000000043.html
（翻譯：PHP100_Alex）
來自：PHP100
相關閱讀
評論(1)