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