Joel 測試(The Joel Test
Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?
Joel測試的好處是很容易快速得出針對每一個問題的“是”或“不是”。你不必去翻出那些每日程式設計行數和每個拐點的平均bug數。如果你的團隊有一個“是”就得一分。關於Joel測試令人失望的是，你真的不應該用它來確保你的核電站軟體的安全。
獲得12分是完美的，11分也還可以容忍，但10分或更低的分數表明你有嚴重的問題。事實上，大多數軟體企業都以2分或3分的分數在運轉著，他們真的很需要幫助，因為像微軟這樣的公司一直以來都以12分的完美表現在運轉。
當 然，這些都不是決定成敗的唯一因素：特別是當你有一個正在開發沒人要的產品的偉大的軟體團隊的時候，那麼，人們是真的不會接受這個產品的。同時一個沒有這 麼做的“神槍手”仍然能產生出令人難以置信的改變世界的軟體也是可能存在的。但是，在其他條件相同的情況下，如果你把這12件事情都做好了，你就會擁有一 個能始終如一完成任務的團隊。
你使用原始碼管理麼？
我用過商業原始碼管理包，也用過CVS，它是免費的，讓我來告訴你，CVS很好用。但如果你沒有對原始碼進行管理，你就要應激嘗試把程式設計師都弄到一塊來工 作。程式設計師根本不會知道別人都做了什麼。犯過的錯誤不能輕易改過來。關於原始碼管理系統的另一個好處就是原始碼本身可以在每個程式設計師的硬碟上進行驗證 —我還從沒聽說過哪個使用原始碼管理的專案丟失了很多程式碼。
你能在一步之內編譯程式麼？
通過這條測試我想明白：從最新的原始碼的快速複製到進行能輸出的編譯需要多少步驟？再優秀的團隊裡，有一個單獨的指令碼，它能從零開始對程式碼做一個全面的檢 查，重新編譯每一行程式碼，生成EXE檔案，在他們各種各樣的版本、程式語言和#ifdef巨集定義組合，建立安裝包和最終媒體–CDROM佈局、下載網站 等等。
如果這個過程需要一個以上的步驟，就很容易出現誤差。當你接近完工的時候，你很想有很快的修復“最後一個”bug的週期，生成最後的EXE檔案等。如果編譯程式碼要用20步才能完成，執行安裝編譯器，……，等等，你會抓狂的，並且會導致你犯下愚蠢的錯誤。
正式由於這個原因，我曾工作過的上個公司就從“聰敏”模式切換到了“軟體安裝打包”模式：我們要求安裝過程中可以執行，使用NT排程從指令碼整晚自動地執行，“聰明”模式做不到這些，所以我們就拋棄了這個模式。
你每天都編譯程式碼麼？
當你使用原始碼管理的時候，有時候程式設計師偶然會檢查出會停止編譯的東西。比如，他們新增了一個原始檔，一切在他們的機器上編譯起來都很好，但他們忘記把源文 件新增到程式碼庫裡了。所以他們鎖定了機器就回家去了，比較健忘也比較高興。但其他人都不能繼續工作了，所以他們也不得不很不愉快地捲鋪蓋回家了。
打斷編譯是很糟糕的（也很常見的），但它能幫助程式設計師每天都編譯程式碼，以確保不會出現沒有預兆的編譯中斷。在大型團隊裡面，一個很好的確保中斷能迅速修復的 方法是每天下午都對程式碼進行編譯，比如可以在午飯時間做這個。每個人都儘可能多地在午飯前做程式碼檢查。這樣當他們吃完午飯回來的時候，這個編譯就已經完成 了。如果它能用，就太好了！每個人都對最新的原始碼進行檢查，然後才繼續工作。如果編譯失敗了，你就修復它，但每個人還能在預編譯、沒有中斷版本的原始碼 上繼續工作。
在Excel專案組，我們有一條規則：誰中斷了編譯，作為對他的“懲罰”，他就要在其他人中斷編譯之前臨時照顧程式碼編譯的工作。這是一個很好的不中斷編譯的激勵方式，也是一個讓每個人輪流參與編譯工作從而都能知道編譯原理的好方法。
你有bug資料庫麼？
我不在乎你怎麼說。如果你在開發程式碼，即使是在一個人的團隊，沒有一個組織的列出程式碼裡所有已知bug的資料庫，你將會產生出低質量程式碼。許多程式設計師都認為 他們能把眾多的bud存在腦子裡。真是胡說八道。我根本就不能再同一時間記住兩個或三個bug，第二天早上，或者在寫程式碼的高峰時期，就記不起它們了。你 絕對要正式地跟蹤bug。
但資料庫可以是複雜或簡單的。一個最小限度的bug資料庫必須包含以下對每個bug的資料：
再次出現這個bug的完整步驟
預期的行為
觀察到的行為
它是被設計來幹嘛的
它是否已被修復
如果bug跟蹤軟體的複雜性是讓你不想跟蹤你的bug的唯一理由，只用上面包含簡單的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。
你有最新的日程安排麼？
這條測試把我們帶到了日程安排上來。如果你的程式碼對生意是很重要的，會有很多知道程式碼完成日期怎麼對生意很重要的原因。程式設計師在制定日程安排上是出了名的倔。“該完成的時候就完成了！”他們會這樣對商務人士尖叫。
不幸的是，這並沒有讓一切變得更好。在發售程式碼之前，公司需要做太多的計劃好的決定：軟體演示，展會，廣告等。而要做到這一點的唯一方法就是擁有一個日程安排，並保證其為最新版本。
關於要有一個日程安排的另一個至關重要的原因是，它能強迫你決定要做哪些功能，然後迫使你挑選出最無關緊要的功能並砍掉它們，而不是陷入長期的猶豫中去。
同時，跟隨日程安排做事並不一定要很苛刻。
你寫程式碼有規範麼？
書寫規範就像牙線，每個人都同意這是一個很好的事情，但卻沒人做。
我不知道這是為什麼，但很可能是因為大多數程式設計師討厭寫文件。結果，對一個大部分有程式設計師組成的團隊遇到了一個難題的時候，他們更傾向於用程式碼來表達他們的解決辦法，而不是用文件。他們寧願埋頭寫程式碼而不是先寫一份規範。
在設計階段，當你發現問題時，你可以很容易地通過編輯幾行文字就修復它。一旦開始寫程式碼，修復問題的代價就大大地提高了，無論在感情上（人們討厭扔掉程式碼） 還是在時間上，所以這時候修復問題是有阻力的。不是從規範開始建立起來的軟體通常會很糟糕地結束設計，並且日程安排會不受控。這個在Netscape好像 已經成為大問題了，Netscape的前四個版本慢慢變得一團糟，然後管理層愚蠢地決定拋棄舊程式碼再重新開始。然後他們又在Mozilla上再一次犯了這 個錯誤，建立了一個失控的怪物，並且浪費了好幾年時間才又回到初始階段。
我的一貫主張是，這問題可以通過把程式設計師送去學習寫作的集中課程，把他們變為差不多的寫手來解決。另一個方案是僱傭一些聰明的程式管理人員，讓他們來寫程式碼規範。在這兩種情況下，你應該執行簡單的規則“無規範不出程式碼”。
程式設計師有安靜的工作環境麼？
廣泛的記錄表明，通過給知識型員工提供空間、安靜和隱私就能提高生產力。經典的軟體管理書《人件》就廣泛地記錄了生產力受益於這些方面。
問題來了。我們都知道知識型員工隨著“靈感流動”工作最好，就是我們所說的“進入狀態”，在哪裡他們會全身心專注於他們的工作，並且完全脫離了周圍的環境。 通過絕對的專注，他們忘記了時間，產生出偉大的程式碼。這是他們把工作完成的過程。作家、程式設計師、科學家，甚至籃球運動員都會告訴你要進入狀態。
問題是，進入狀態並不那麼容易。當你嘗試去考量它的時候，在最大生產力下好像需要15分鐘才能開始工作。有時，如果你累了或那天已做了很多創造性工作時，你就是進入不了狀態，你會把這天剩下的時間都用來擺弄點什麼，看看網頁，或玩玩俄羅斯方塊。
另一個問題是，很容易脫離那個狀態。噪聲，來電話，出去吃午飯，不得不開5分鐘車去星巴克喝咖啡，還有被同事打擾–尤其是被同事打擾–都會把你從那個狀 態里拉出來。如果同事問你問題，導致了一分鐘的中斷，但這個會很悲慘地把你從狀態裡脫離出來，你的話費半個小時才能再次變的高效起來，你的整體生產力會遇 到很大的麻煩。如果你在一個含咖啡因的網路公司喜歡創造的嘈雜的牛棚一樣的環境裡，有營銷人員在程式設計師身邊尖叫著打電話，你的工作效率會大幅下跌，因為知 識型工作者一次又一次的被打斷，一直都進入不了狀態。
對程式設計師來說，這就更難了。工作效率依賴於能夠同時在短期記憶中兼顧很多小細節。任何型別的打斷都會導致這些細節轟然倒下。當你重新開始工作，你已經記不起 任何細節（比如你剛才還在使用的本地變數名字，或你剛想出來的實施搜尋演算法的好點子）了，你不得不一直回想這些事情，這會讓你變得很慢，直到你重新變得高效起來。
這有一個簡單的代數運算。可以這麼說（有證據暗示）如果我們打斷了一個程式設計師，即使只有一分鐘，我們真的會失去15分鐘的工作效率。在這個例子裡，我們假設 有兩個程式設計師，Jeff和Mutt，在一個標準的相鄰開放的格子間裡。Mutt記不起strcpy函式的Unicode版本的名字。他可以查一查，這需要 30秒，或者他可以問問Jeff，這需要15秒。因為他就坐在Jeff旁邊，所以他選擇直接問Jeff。Jeff被分心了，失去了15分鐘的工作效率（僅 僅節省了Mutt的15秒）。
現在我們把他們兩個分到有門和牆隔開的兩個辦公室去。這時如果Mutt忘記那個函式名，他可以花30秒去查一查，或者花45秒去問問Jeff，這過程包括了 站立起來（考慮到程式設計師的平均體能這並不是一項簡單的任務！）。所以他會選擇自己查一查。這樣Mutt失去了30秒的工作效率，但同時為Jeff節省了 15分鐘。哈哈哈哈！
你用錢能買到的最棒的工具麼？
在公園裡使用家用電腦立即用一門編譯語言寫程式碼仍然是最不能做的事情之一。如果你的編譯過程超過幾秒鐘，使用最新和效能最強的電腦會讓你節省點時間，當編譯 器執行的時候，程式設計師會感到厭倦，這是他們會切換到閱讀點別的書籍，這會吸引他們的注意力，失去好幾個小時的工作效率。
使用單個顯示器除錯GUI程式碼是很痛苦的，這也不是不可能。如果你在寫GUI程式碼，兩臺顯示器會讓很多事情變得更加容易。
大多數程式設計師最終要處理圖示或工具欄的點陣圖，但他們大多數都沒有一個好用的點陣圖編輯器。嘗試用Microsoft Paint來處理點陣圖是個笑話，但這就是大部分程式設計師們所要做的。
在我上一份工作中，系統管理員一直給我發自動的垃圾郵件抱怨，說我用了超過220兆位元組的伺服器上的硬碟存貯空間。我指出，鑑於最近硬碟的價格，這些硬碟空 間的成本比我使用的衛生紙的成本都低多了。甚至花費我10分鐘來清理我的郵件目錄，這真是對我工作效率的極為荒誕的浪費。
頂尖的開發團隊不會折磨他們的程式設計師。即使是因為功能不完善的工具引起的小挫折累加起來，也會使程式設計師脾氣暴躁和不愉快。一個脾氣暴躁的程式設計師是不會有工作效率的。
程式設計師最容易接受最酷、最新的東西賄賂了。與支付有競爭力的薪水比起來，這是一種讓他們為你工作更便宜的方式。
你有測試人員麼？
如果你的團隊沒有專門的測試人員，至少應該為兩三個程式設計師就配一個測試人員，你會寫出有很多bug的產品，或者你在花冤枉錢讓測試人員30刀每小時就能做的 工作交給100刀每小時的程式設計師來做。在測試人員身上節省下來的錢是一個離譜的虛假的經濟，我只是想讓更多的人認識到這一點。
找工作的人面試時會寫程式碼麼？
你會僱傭一個沒看過他魔術技巧的魔術師麼？當然不會。
你會僱傭一個沒嘗過他的食物的餐飲服務商來為你的婚禮服務麼？我對此表示懷疑。
然而，一天天的，程式設計師通過讓人印象深刻的簡歷被僱用，或是因為面試者喜歡跟他們聊天。或者他們被問到很細的問題（“CreateDialog（）和 DialogBox（）之間有啥不同？”），這些看文件就能回答了。你不關心他們是否記得關於程式設計的成千上萬的細節，你只關心他們到底能不能寫出程式碼。或 者，更糟糕的是，他們被問到的都是“啊？”問題：就是那種你知道答案就看起來很簡單，但如果不知道答案就什麼也回答不上來的問題。
拜託，以後不要這麼幹了。在面試期間你想怎麼問就怎麼問，但一定要讓參加招聘的程式設計師寫點程式碼。
你會做走廊可用性測試麼？
走廊可用性測試就是當你在走廊上遇到一個路人就強迫他試著用你剛寫的程式碼。如果你對五個人做過這種事，你會學到你程式碼裡需要學習的95%的實用性問題的答案。
好的使用者介面設計並不像你想的那麼難，如果你想讓使用者喜歡併購買你的產品這就至關重要了。
但關於使用者介面最重要的事情是，如果你把你的程式展示給很多人看（實際上五六個就足夠了），你就會發現人們存在的最大的問題。即使你的使用者介面設計技術還不怎麼樣，只要你強迫自己去做走廊可用性測試，這並沒什麼代價，而你的使用者介面會越來越好的。
相關閱讀
評論(1)