此節(jié)為第一部分的第三節(jié)：
JOEL測試：改進代碼的12個步驟
JOEL測試
1
、使用源控制代碼嗎？
2
、能一步完成連編嗎？
3
、每天都做連編嗎？
4
、有故障信息數據庫嗎？
5
、在編寫新代碼之前修復故障嗎？
6
、有最新的進度表嗎？
7
、有規(guī)格說明書嗎？
8
、程序員擁有安靜的工作環(huán)境嗎？
9
、你用到了你資金能力內可買到的最好工具嗎？
10
、有測試人員嗎？
11
、新聘人員在試用期寫代碼嗎？
12
、進行走廊可用性測試嗎？
在這一節(jié)中例出了JOEL測試的12個步驟，個人覺得確實把一些標準軟件測試的精華吸取進去了，卻又拋棄了各類標準測試中的過于嚴格、限制靈活性的部分。當然這也如書中所說的，“Joel測試的不足之處，處是，確實不應該用它來保證核動力工廠軟件是安全的”。作為個人來講，應該把這些測試作為一種軟件開發(fā)的習慣（當然，只是有些部分哦！~）。
在這里把比較精要的地方記錄一下：
1、不使用源控制，程序員沒有辦法知道其他人員做了什么，所以不容易進行錯誤回滾。源控制系統(tǒng)的另外一個巧妙之處在于，可保證源代碼在每個程序員的硬盤上都是經過自動確認了的。
2、從最新的源快照進行一次可分發(fā)的連編，需要多少個步驟？在一個優(yōu)秀的團隊通常會維護一個腳本，通過運行它，可以從頭至尾地進行一次檢查；重新編譯每一個代碼行；并按其不同的版本、語言以及條件編譯語句#ifdef來生成EXE文件；創(chuàng)建安裝包；并且生成最終的表現介質——CD-ROM、下載頁面等。如果這樣的過程需要多步才能完成，那么就很可能出錯，并且越接近產品分發(fā)時刻，就越希望修復“最后故障”、形成最終EXE文件等操作所經歷的周期會更短一些。JOEL指出不應該有20步。
3、無論誰中斷了連編，都要負責修復連編操作，直到有別人中斷連編過程為止。這是JOEL在Excel開發(fā)團隊采用一種激勵不要中斷連編過程的機制，同時也讓大家弄清楚連編是如何進行的。
4、故障信息數據庫。一個可用的故障信息數據庫必須至少為每個故障包含如下數據：重現故障的完整步驟、預期功能、觀察到的（故障）行為、要分配誰、是否已修復。
5、發(fā)現故障到準備修復故障之間等待的時間越長，付出的代價（時間與金錢上）就越大。微軟普遍采取了一種稱之為零缺陷法（zero defects methodology）的措施。零缺陷意味著在任意給定時間點，最需要優(yōu)先去做的事情是在寫任何新的代碼之前消除故障。這也可以是一個衡量進度表的標準：如果你已經修復了所有已經知道的故障，并且剩下的就是編寫新代碼，那么進度表就是極其準確的。
6、擁有一個好的進度表的優(yōu)點：保證它始終反映最新的項目情況；迫使你做出將要實現什么功能的決定，然后強迫你揀出最不重要的功能，并加以剪除而不是陷入功能沼澤地帶（也就是功能范圍蔓延開來）。
7、“沒有規(guī)格說明書就沒有代碼”。不是根據規(guī)格說明書開發(fā)出來的軟件通常會因設計欠佳而停滯不前，從而使進度失去控制。
8、JOEL舉了一個比較好的例子：Mutt記不住Unicode版本的strcpy函數的名字。他可以查詢該函數，這要花費30秒鐘的時間；他也可以詢問Jeff，這得用去15秒鐘的時間。既然緊靠Jeff坐著，他選擇詢問Jeff。不過，Jeff因此顯得心煩意亂而丟掉了15分鐘的產出（僅僅為了節(jié)省Mutt 15秒鐘）。然而如果當Mutt去詢問Jeff需要45秒鐘的時間時，Mutt就會去選擇自己去查詢了。
9、可以顯著地提高開發(fā)效率，同時程序員是容易通過給他們提供最棒最新的東西而得到滿足的，這是一種遠比通過支付極富競爭力的薪力來促使他們?yōu)槟愎ぷ骱玫枚嗟耐緩健?/p>
10、沒有專門的測試人員，意味著要么分發(fā)充滿故障的產品，要么通過讓價值$100/小時的程序員去做那些能夠讓價值$30/小時的測試人員完成的工作。
11、一定要讓應聘者編寫一些代碼。
12、走廊可用性測試指的是，在走廊里隨便抓一個從身邊走過的人，要他試著使用你所編寫的代碼。如果對5個人進行了這類測試，那么就可以了解隱藏在代碼中的95%的可用性問題。