# 三、joel測試：改進代碼的12個步驟 你曾經聽說過SEMA嗎？ [1]它是一個相當深奧的系統，用于測試軟件團隊優良程度。不，等 一下！不要去讀SEMA!要理解這個東西就得花大約6年的時間。因此，我自己提出了一套 不很嚴格的寬松測試來評估一個軟件團隊的質量。該測試的閃光之處在于它只需花費大約三 分鐘的時間。將節省下來的所有時間利用起來，你就可以進入醫學院了。 Joel測試 1. 使用源控制機制嗎？ 2. 能一步完成連編嗎？ 3. 每天都做連編嗎？ 4. 有故障信息數據庫嗎？ 5. 在編寫新代碼之前修復故障嗎？ 6. 有最新的進度表嗎？ 7. 有規格說明書嗎？ 8. 程序員擁有安靜的工作環境嗎？ 9. 你用到了你資金能力內可買到的最好工具嗎? 10. 有測試人員嗎？ 11. 新聘人員在試用期寫代碼嗎？ 12. 進行走廊可用性測試嗎？ Joel測試的巧妙之處在于，針對每個問題，都可以很容易得到“是”或者“不”的回答， 沒必要弄清每天的代碼行，或者每個測試點的平均故障數。對每個做出“是”的回答，給團 隊加上一分。Joel測試的不足之處是，確實不應該用它來保證核動力工廠軟件是安全的。 得12分是極好的，11分可以容忍，但10分或者更低就是嚴重的問題了。現實情況是，大 多數軟件機構正運轉在2或3分上，它們需要正式的幫助，因為像Microsoft這樣的公司全 天候運轉在12分上。 當然，這些內容不是決定成功或者失敗的惟一因素。特別是，假設一個大型的軟件團隊正在 努力開發一個沒人想要的產品，對了，人們就是不會要它。這就好比是一支由“槍手”組成 的隊伍，他們做的事情與此毫不相干，卻仍然設法生產能夠改變世界的令人難以置信的軟件。 但是，萬事萬物都有可比性，如果將這12件事情辦妥了，那么就有了一個可以隨時投入使 用的訓練有素的團隊。 ## 1.使用源控制機制嗎 我使用過商業版本的源控制包與免費的CVS[2]，并且，我要說CVS不錯。但是，如果不使 用源控制，那就得十分強調盡力讓程序員在一起工作。程序員沒有辦法知道其他人員做了什 么，所以不容易進行錯誤回滾。源控制系統的另外一個巧妙之處在于，可保證源代碼在每個 程序員的硬盤上都是經過自動確認了的一一我從來沒有聽說使用源控制的項目丟失過許多 代碼。 ## 2.能一步完成連編嗎 對于這一點，我的意思是：從最新的源快照進行一次可分發的連編，需要多少個步驟？ 一個 優秀的團隊僅有一個能夠做從頭至尾的完全校驗的有效腳本；可重建每個代碼行；按所有不 同的版本、語言組合來建立EXE文件；創建安裝包；生成最終介質一一CD-ROM規 劃；下載Web站點，等等。 如果這樣的過程需要多步才能完成，那么就很可能出錯，并且越接近產品分發時刻，就越希 望修復“最后”故障、形成最終EXE文件等_*_作所經歷的周期會更短一些。如果要用20 步才能完成代碼的編譯與安裝程序的生成等任務，那么你因為感到煩躁而很可能犯低級錯誤。 正是因為這個原因，我供職的最后一家公司就從當初使用Wise到現在改用InstallShield 了 ：我們要求安裝過程能夠通過使用NT調度表通宵自動地從腳本運行，而Wise不能在晚上 從調度表啟動，因此我們將它扔掉了。（友善的Wise人向我保證，他們的最新版本一定支 持夜晚連編功能。） ## 3.每天都做連編嗎 使用源控制時，程序員時常不經意地加入一些東西，導致連編中斷。比如說，他們添加了一 個新的源文件，但是忘記了將該源文件添加到代碼庫中去。這在他們自己機器上編譯是很好 的，于是，他們鎖上機器回家去了，心情舒暢而愜意。不過，別人卻不能工作，但也只好回 家去，心情郁悶而憂心忡忡。 中斷連編過程是如此有害（同時也如此常見），以致它反而有助于保證每天的連編不至于出 現中斷沒有被覺察的情況。在大型軟件團隊中，確保中斷得以立即修復的一條很好的途徑是， 在每天的午餐時間實施每天都要進行的連編過程。每個人在午餐之前都盡可能多地進行加注 新內容的工作。當他們回來時，興許連編己經做完了。要是這個辦法可行，就好極了！大家 在核實最新的源文件版本以后繼續工作。如果連編失敗了，就得進行修復，不過，也可以從 連編過的沒有發生中斷的源文件版本重新再來。 我給Excel開發團隊制訂了一條規則，無論誰中斷了連編，都要負責擔當連編_*_作的臨時 保姆以示“懲戒”，直到有別人中斷連編過程為止。這是一條激勵大家不要中斷連編過程的 好機制，也是讓大家輪流進入連編進程的好途徑，從而使每個人弄清連編是如何進行的。 關于每日連編方面的更多內容，可閱讀我寫的《每日連編是朋友》[3]—文。 ## 4.有故障信息數據庫嗎 我并不在乎你說些什么。如果你正在開發代碼（即使是只有一個人的團隊），但是沒有一個 組織嚴密，并列舉了代碼中所有己知故障的數據庫，那么分發出去的代碼的質量可能是很低 的。許多程序員認為能夠做到在自己的頭腦中放一份故障信息表。這是胡說！反正我一次記 不住兩條或者三條以上的故障信息，也許就在第二天早上或者代碼分發的一剎那，將它們忘 得干干凈凈。可見，絕對需要正式地保存一份故障信息記錄。故障信息數據庫可以很復雜， 也可以很簡單。一個可用的故障信息數據庫必須至少為每個故障包含如下數據： * 重現故障的完整步驟 * 預期功能 * 觀察到的（故障）行為 一要分配給誰 一是否己修復 如果故障跟蹤軟件的復雜性是阻止你跟蹤故障的惟一因素，那么建立一個包含上述關鍵信息 的五字段關系表，然后開始使用它。 關于故障跟蹤方面的更多內容，可閱讀《故障輕松跟蹤》一文[4]。 ## 5.在編寫新代碼之前修復故障嗎 Microsoft Word的第一個真正Windows版本曾被認為是一個“死亡之旅”項目。它花費的 時間不計其數，并且常常脫開正常軌道。整個開發團隊行進在看不到盡頭的工作泥沼之中， 項目經過了延遲、延遲與再延遲，壓力大得難以置信。幾年以后，當這個響當當的物件終于 分發下去時，微軟將整個開發團隊送到迦南去度假，從而坐下來做某種嚴肅而深刻的靈魂自 我反省。 他們意識到，項目經理們一直是如此固執地堅持按時間表行事，以致使程序員只顧趕進度而 編寫出極其糟糕的代碼，因為故障修復階段并沒有成為正式進度表的一部分。整個團隊沒有 在縮減故障數量方面做出任何努力，而是與此恰恰相反。 整個情景演變為：一個必須通過寫代碼來計算文本行高度的程序員只是簡單地給出”return 12 ”這樣的代碼了事，然后就等故障報告出來，故障報告總是說他的函數不正確。到頭來， 進度表只不過成了一張功能故障列表。在尸檢行業，這稱之為無限缺陷法（infinite defects methodology)。 為糾正出現的問題，微軟公司普遍米取了一種稱之為零缺陷法(zero defects methodology) 的措施。公司的許多程序員對此報以咯咯一笑，因為這聽起來就像是一種單純依_*_行政命 令就能減少故障數目的管理思想。其實，零缺陷意味著在任意給定時間點，最需要優先去做 的事情是在寫任何新的代碼之前消除故障。下面說說這樣做的理由。 一般說來，在修復故障之前等待的時間越長，付出的代價（時間與金錢上）就越大。 比如，當編譯器捕捉到一個拼寫或者語法錯誤，然后去修正它基本上是小事一粧。 在首次試圖運行代碼時所看到的錯誤，可以毫不費事地立即進行修正，因為所有代碼在頭腦 中仍然十分清晰。 如果在幾天前編寫的代碼中發現了問題，找到它確實需要花費一些工夫。不過，只要重新閱 讀編寫的代碼，就可以回想起所有的事情，從而在合理的時間里把它修正過來。 但是，假如在幾個月以前寫的代碼中發現了問題，就可能己經忘記了代碼方面的許多事情， 要修復故障就困難多了。這個時候倒是可以去對別人的代碼進行糾錯，編寫代碼的人可能正 在阿魯巴島（阿魯巴島是拉丁美洲荷屬安的列斯群島中的大島，譯者注）度假。在這種情況 下，修理故障就跟從事科學工作一樣：你得慢慢地、系統而小心翼翼地行事，并且不能確定 要花多長的時間才能糾正錯誤。 然而，要是在己經分發出去的代碼中找到了缺陷，那么要修復它所要付出的代價將是難以置 信的。 這就是要立即修復故障的一個理由：因為這樣做花費的時間較少。下一個理由與這樣一個事 實有關：預測要花多長時間去編寫新代碼比預測要用多少時間去修復現有故障容易得多。 比如，假設叫你預測要花多長時間去編寫一段進行列表分類排序的代碼，你一定能夠給出一 個相當好的估計。但是，如果叫你預測要花多少時間去修復代碼在安裝了 Internet Explorer 5.5版本以后無法工作的故障，你恐怕連猜也猜不出來，因為你不知道（從概念 上講）故障出現的原因。很可能要用三天的時間去把故障跟蹤出來，也可能只要兩分鐘就夠 了。 這里要表達的意思是，如果進度表包含了許多有待修復的故障，那么該進度表就是不可_*_ 的。但是，如果你己經修復了所有己經知道的故障，并且剩下的就是編寫新代碼，那么進度 表就是極其準確的。 關于將故障數目維持在零的措施有另外一個重大意義，可以對競爭做出快得多的反應。一些 程序員一直將這看做是讓產品做好分發的準備。然后，如果競爭對手加入一個“殺手锏”新 功能來搶奪顧客，你就可以只去實現此新功能，并即時分發產品，而用不著去修復一大堆累 積起來的故障。 ## 6.有最新的進度表嗎 這個因素促使我們按進度表推進。如果代碼對業務顯得十足重要，那么必定有許多關于它為 什么對業務重要的理由可用以了解代碼要在何時完成。程序員在制訂進度表方面所顯現出來 的執拗，給他們留下了壞名聲。“在該做的時候自然就做了！”他們沖著業務人員大聲喊叫 道。 遺憾的是，事情遠還沒有完。在分發代碼之前，需要業務部門去很好做出的規劃決策太多了， 這包括產品演示、貿易展示與廣告等。做這件事的惟一途徑就是擁有一個進度表，并保證它 始終反映最新的情況。 擁有進度表的另外一個至關重要之處在于，它首先迫使你做出將要實現什么功能的決定，然 后強迫你揀出最不重要的功能，并加以剪除而不是滑入功能沼澤地帶（也就是功能范圍蔓延 開來）[5]。 持有進度表并不意味著必定顯得困難重重。不妨閱讀一下第9章，其中給出了一種創建大進 度表的簡單方式。 ## 7.有規格說明書嗎 寫規格說明書好比是理亂麻：人人都認為是好事情，可就是沒人去做。 雖然我吃不準這是為什么，但覺得很可能是因為大多數程序員都討厭寫文檔資料的緣故。于 是乎，當僅僅由程序員組成的團隊在攻克一個問題時，他們偏向于用代碼而不是以文檔資料 來表示其解法。他們更寧愿匆匆忙忙地一開始就大寫特寫代碼，而不是首先制訂一個規格說 明書。 在設計階段發現問題時，可以通過編輯幾個文本行而容易地修復它們。一旦代碼寫完，糾正 錯誤所付出的代價會高得出奇，這包括情感（人們通常都厭恨丟棄代碼的行為）與時間兩方 面的原因。因此，實際消除問題是有阻力的。不是根據規格說明書開發出來的軟件通常會因 設計欠佳而停滯不前，從而使進度失去控制。這個問題好像己經在Netscape瀏覽器那里出 現過，它開頭的四個版本逐漸變得混亂不堪，致使管理層愚蠢地決定丟棄己寫成的代碼而從 頭開始[6]。而后，他們再次在Mozilla上完全重復了這一錯誤而創建出一個讓公司運作逐 漸失去控制的怪物，整整花了幾年的時間才推進到a階段。 按照我提出的嬌慣理論，這個問題的一種解決之道是通過將程序員送去參加一個寫作方面的 強化班[7]而教他們成為不那么湊合的作者。另外一種解決辦法是聘用聰明能干的程序管理 人才，由他們負責編寫規格說明書。使用這里給出的任何一種方式，都應該強調那條簡單的 規則一一 ”沒有規格說明書就沒有代碼！〃 讀者可以閱讀本書第5~8章，學習關于寫規格說明書的所有內容。 ## 8.程序員擁有安靜的工作環境嗎 大量的文獻表明，通過給能干的工作人員提供寬敞、寧靜和獨立的工作環境，可以獲得很高 的生產效率。軟件管理方面的經典書籍《人件》（Peopleware)全面論述了這類生產效益的 有關情況[1]。 現在來說明它是如何發揮作用的。大家知道，熟練員工一旦做到“順手”（也稱之為進入狀 態）就工作得最好。這個時候，他們將全部精力集中在自己的工作上而置身于環境之外。他 們忘記了時間，因為精力特別集中而煥發出很高的生產率。這正是他們完成所有可做之事的 時候。作家、程序員、科學家乃至籃球隊員等人士都可以說出什么叫進入狀態。 問題在于，進入狀態并不是件容易做到的事情。測量結果表明，人們平均起來似乎要經過 15分鐘才開始進入效率最高的狀態。有時候，如果你比較勞累或者己經在當天做了很多創 造性的工作，那么你就不能進入最佳狀態；在剩下的工作時間里，所要做的事情就是把周圍 整理一下、上一上網或者玩玩跳跳棋。 另外一件麻煩事情是被干擾而退出興奮點卻非常容易。噪音、電話、出去吃午飯、不得不驅 車5分鐘去喝咖啡，以及被同伴打斷一一被同伴打斷尤為突出，這些事情都可以使人退出興 奮區。如果雖然同伴問你一個問題只將工作中斷了一分鐘，但是這足以讓你花半小時的時間 再重新進入狀態，那么你的總體工作效率就很嚴重了。如果置身如咖啡網吧傾向于營造的那 種人多嘈雜的大房間環境之中，外加幾個市場推銷員在程序員旁邊喋喋不休地聒噪，那么生 產效率將隨著熟練員工一次又一次地被打斷而打了水漂，你永遠也進入不了狀態。 對于程序員來說，這尤其很難。生產效率與能夠立即改動腦子里短期記憶的許多細節有關。 任何類型的中斷都能夠使這些細節盡皆消失。在重新恢復工作時，任何細節（像正在使用的 局部變量名或者著手實現搜索算法的地方）都想不起來了，從而只得再次把它們找出來，這 會極大地降低工作速度，直到工作重新變得順手為止。 它涉及的代數知識并不復雜。毫不客氣地說（正如有證據似乎表明的那樣），即便是打斷程 序員一分鐘，我們其實打掉了他15分鐘所創造的效益。作為這方面的一個例子，讓我們將 程序員Jeff與Mutt彼此緊挨著安排在某標準Dilbert肥牛場中一個開放的小臥室里。Mutt 記不住Unicode版本的strcpy函數的名字。他可以查詢該函數，這要花費30秒鐘的時間； 他也可以詢問Jeff，這得用去15秒鐘的時間。既然緊***Jeff坐著，他選擇詢問Jeff。不 過，Jeff因此顯得心煩意亂而丟掉了 15分鐘的產出（僅僅為了節省Mutt 15秒鐘）。 現在讓我們將他二兩人移到有墻有門的獨立辦公室中去。這個時候，Mutt記不住那個函數 的名字，他可以查詢該函數，仍然要花費30秒鐘的時間；他也可以詢問Jeff，現在得用去 45秒鐘的時間并且意味著站起來走一趟(在現有程序員平均身體狀況下，很少會那么做！）。 于是，Mutt決定自己去查詢該函數的名字。如此一來，雖然現在Mutt損失30秒鐘的產出， 但我們為Jeff節省了 15分鐘。啊哈！ ## 9.你用到了你資金能力內可買到的最好工具嗎 用編譯語言編寫代碼，仍然是在像花園一樣多姿多彩的家用電腦上不能立即做成的最后幾件 事情之一。如果編譯過程要用幾秒鐘以上的時間才能完成，那么使用最新最好的計算機將可 以為你節省大量時間。即使編譯過程只需要15秒鐘，在編譯器運行時，程序員也會感到無 聊，從而可能轉過去閱讀《洋蔥》[2]，這會使他著迷，于是幾個小時的開發效益就沒有了。 用單監視器系統調試GUI代碼是很頭疼的，盡管不是不可能。寫GUI代碼時，使用兩個監視 器會使事情容易得多。 大多數程序員最終都會因為圖標或者工具欄而_*_作位圖，并且他們大多沒有很好的位圖編 輯器可用。雖然試圖使用Microsoft Paint來處理位圖不啻是個笑話，但這是大多數程序員 不得不去做的事情。 在我最新從事的一項工作中[3]，系統管理員一直不斷地給我發送自助午餐肉（信息）。他 抱怨說，我為此占用了服務器上多達220MB的硬盤空間。我指出，以當前的硬盤驅動器價格 論，這個空間的花銷遠遠低于我使用的手紙的費用。我哪怕花10分鐘來清除我的目錄，也 將使生產效率造成驚人的浪費。 拔尖的開發團隊是不讓程序員遭受磨難的。它會盡可能不讓程序員因為使用功能不強的工具 而遇到挫折，以免程序員心情煩躁而感到不愉快。煩躁不安的程序員不屬于高產的程序員之 列。 說到底，程序員是容易通過給他們提供最棒最新的東西而得到滿足的。這是一種遠比通過支 付極富競爭力的薪水來促使他們為你工作，要廉價得多的途徑！ ## 10.有測試人員嗎 如果團隊沒有專門的測試人員（至少為每兩個或者三個程序員配備一個測試人員），那么意 味著要么分發充滿故障的產品，要么通過讓價值 30/小時的測試人員完成的工作而浪費錢財。在測試人員方面吝惜錢財談不上節儉，這種做 法顯得不可理喻，我只能是嗤之以鼻地說，較多的人不會認可它。第22章對該內容會有更 多的介紹。 ## 11.新聘人員在試用期間編寫代碼嗎 你會聘用一個魔術師而不叫他露幾手戲法嗎？當然不會。你會讓酒店老板承辦婚禮宴席而不 品嘗他們的菜肴嗎？這很難說。（Marge阿姨除外，你要是不讓她做她“著名的”碎肝餅， 她會嫉恨你一輩子。） 盡管如此，每天仍然有一些程序員是因為持有令人印象深刻的履歷或者面試人員喜歡跟他們 聊天而被聘用的。或者他們只是被問了一些非常瑣碎的問題（比如說“C「eateDialog〇與 DialogBox()之間有什么不同？ ”），這些問題是可以通過查看文檔資料得以作答的。用不 著在意他們是否記住了編程方面成千上萬的細枝末節，應該在乎的是他們能否構造代碼。甚 或還有更為糟糕的情況，那就是程序員被問了一些“打哈哈”的問題一一這些問題如果你知 道答案似乎顯得很容易，可要是你不知道答案，要回答出來就顯得極為不可能。 務請停止這樣的做法。誠然，你可以在面試期間做想做的任何事情，但是一定要讓應聘者編 寫一些代碼（關于這方面的更多建議，可閱讀我的《面試游擊戰指南》一文，本書的第20 章收錄了該文。） ## 12.進行走廊可用性測試嗎 走廊可用性測試指的是，在走廊里隨便抓一個從身邊走過的人，要他試著使用你所編寫的代 碼。如果對5個人進行了這類測試，那么就可以了解隱藏在代碼中的95%的可用性問題。 好的用戶界面設計并不像你想像的那樣難，并且，它對于顧客喜愛與購買你的產品至關重要。 我寫的關于用戶界面設計的書[4]集中敘述了這方面的內容，它是為程序員所寫的一個初級 讀本。 不過對于用戶界面最為重要的事情是，如果將程序交給一部分人（事實上，5~6個人就夠了） 看，那么你會迅速發現人們掌握著最大的問題。關于這方面的原因，可閱讀Jakob Nielsen 的有關文章[5]。即使你的U I設計技能很缺乏，但是只要強迫自己進行走廊可用性測試（這 用不著付出什么代價），那么設計出來的UI將是非常非常好的。 ## 使用Joel測試的四種途徑 1. 評價自己的軟件機構，并說出是如何評價的，這樣我可以與你交流一下了。 2. 如果你是程序設計團隊的經理，那么使用該測試作為校驗表，以保證團隊確實在盡可能 地發揮作用。如果一開始就評定一個團隊為12分，那么可以集中精力不使業務人員去打擾 程序員而使他們置身其外[6]。 3. 如果你在決定是否接受一項編程活件的話，那么詢問你未來的雇主在該測試上的得分情 況如何。如果測試的分值太低，那么就要確保自己有權威去修正這種局面。否則，你會面臨 失敗而徒勞無益。 4. 如果你是一位正在努力評判某個程序設計團隊的價值的投資人，或者你的軟件公司正在 考慮與另外一家公司合并，那么這個測試可以提供一個快速而簡易的尺度。 //后記：2004年6月14日 //自從Joel測試在2000年8月推出以來，我從世界各地的開發人員那里收到了成堆的匯報 各自團隊如何評分事宜的 //電子郵件。盡管結果的分布顯得相當均勻，我還是要說，絕大多數分值處在2與3之間的 一個位置。嗯！我也收到 //一些在無組織的“槍手”軟件開發實踐當中成長起來的開發人員的來信，他們拒絕從那些 看起來在Joel測試方面 //天生只能得低分的公司招攬新活。并且，我還收到一些團隊經理給出的杰作，他們以Joel測試作為提高團隊素質 //的進階過程而推進自己的管理工作。 //與此同時，似乎許多軟件開發組織己經遠遠地走出了 Joel測試的范疇，而進入復雜的官 僚政治動脈硬化苦斗之中 //。什么時候會出現這種情況是很容易說出的，因為人們在準備開會方面所花的時間比開發 軟件更多。在Joel測試 //上得到12分的不錯成績，然后就被多如牛毛的政治活動糾纏得脫不開身而做不了什么事 情，這是很有可能發生的 //一種情況。 //沒有必要告訴別人是我說了些什么，不過，自上世紀90年代初我在微軟公司工作的那個 時期以來，所有證據都表 //明，該公司或多或少地擱淺乃至停滯均是因其過于龐大的規模、內部政治紛爭與官僚系統 的不檢點所致。還需要 //證據嗎？ //Tablet PC 一一這是一種只有微軟公司的中層經理們才可能喜愛的東西一一似乎設計成了 讓華盛頓Redmond的程 //序經理們可以開一整天的會，卻不至于使其日常電子郵件處理事宜顯得過于滯后。這不單 純只是微軟才存在的現象。 //如果突然間地發現自己在安裝與配置巨無霸軟件開發系統或“什么什么可視化企業體系設 計大師”之類的軟件方 //面，花費的時間太多，或者說要開始開發產品時還在團隊重新學習“極限編程（Extreme Programming)”與 //UML方面反反復復而讓他們腦袋變大，那么即使在Joel測試方面真的做得不錯，你還是 可能陷入困境。 [1]見Tom DeMarco與Timothy Lister合著的《人件:高產項目與團隊》第2版（Peopleware: Productive Projects and Teams, Second)，該書由 Dorset 出版社于 1999 年出版發行。 [2]見 [http://www.theonion.com](http://www.theonion.com) 。 [3]見第32章。 [4]Joel Spolsky 著的《程序員用戶界面設計KUser Interface Design for Programmers) (Apress于2001年出版）。該書的一部分可以從 [http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html](http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html) 上免費使用。 [5]Jakob Nielsen寫的“為什么只需測試5個用戶”一文于2000年3月19日在.useit.com 上發表。詳細內容見 www.useit.com/alertbox/20000319.html 。 [6] www.joelonsoftware.com/articles/fog0000000072.html 。