Chapter 03
約耳測試:邁向高品質程式碼的12個步驟
2000年8月9日,星期三
你曾聽說過SEMA嗎(*1)?這是一套相當深奧的系統,可以測量軟體團隊的好壞。等一下!不要急著連過去看,我想光是要搞懂那個東西大概就要花上你六年的時間。所以我自己有一套無責任的簡易方法來衡量軟體團隊的品質,這套方法的好處是只要花3分鐘,省下的時間足夠讓你唸一趟醫學院。
約耳測試(Joel Test)
1. 你有使用原始碼控制系統嗎?
2. 你能用一個步驟建出所有結果嗎?
3. 你有進行每日編譯嗎?
4. 你有沒有問題資料庫?
5. 你會先把問題都修好之後,才寫新的程式嗎?
6. 你有一份最新的時程表嗎?
7. 你有寫規格嗎?
8. 程式設計人員有沒有安靜的工作環境?
9. 你有沒有用市面上最好的工具?
10. 你有沒有測試人員?
11. 是否在面試時要求面試的對象試寫程式?
12. 是否進行過走廊使用性測試?
1 詳見www.sei.cmu.edu/sema/welcome.html。(編註:原址已失效,請參考http://www.sei.cmu.edu/measu。)
約耳測試的好處是每個問題都很直覺,只要回答是或否。你不必計算每天寫的程式行數、或是每個重大時點的平均問題數量,只要答「是」就加 1分。約耳測試的缺點是絕對不能用來確保核電廠的安全性。得到 12分是完美, 11分勉強可接受,不過 10分以下(含 10分)就表示問題大了!事實上,大部分軟體組織只拿到 2或3分,而這些組織都岌岌可危,因為微軟隨時都是以12分的水準在運作。
當然,這些並不是決定成敗的唯一因素;特別是當你的優秀團隊盡做些沒人要的產品時(對,沒人要)。另外,也可能有那種「高手」團隊,即使完全不理會這些東西,卻仍能做出改變世界的夢幻軟體。不過,除此之外所有人都一樣,如果你能把這 12件事做好,就能建立一個能穩定交出產品的紀律團隊。
1.你有使用原始碼控制系統嗎?
我使用過一些商用原始檔控制系統( source control packages),也用過免費的 CVS(*2),所以我可以告訴你 CVS相當不錯!如果你沒有原始碼控制系統,一旦需要與程式設計人員合作就相當麻煩了。因為程式設計人員無法知道其他人做了什麼,也無法輕易回復成出錯前的狀態。而且原始碼控制系統還有另一個優點,就是原始碼會被簽出( check out)到每位程式設計人員的硬碟裡。我還沒看過哪個用了原始碼控制的專案會遺失大量程式的。
2 參考wwwcvshome.org/。
2.你能用一個步驟建出所有結果嗎?
我的意思是:從最新的原始碼快照開始,要花多少步驟才能建立出貨用的軟體?好的團隊會有單一個腳本檔,只要執行這個腳本,就會從頭簽出所有檔案、編譯每一行程式、建立執行檔(包含所有不同版本、語言以及#ifdef組合)、製作安裝程式,並且產生最後要用的媒體格式:光碟片、網站下載或是其他各種格式。
如果這個程序不是只有一個步驟,就會容易出錯。另外,當出貨時程緊迫時,修正「最後一個(*3)」問題、製作最終執行檔等過程必須要快速完成。如果程式編譯和安裝檔製作等動作需要20個步驟才能完成,你一定會急瘋了,然後做出一些蠢事。
就是為了這一點,我的前一家公司把原本使用的 WISE換成InstallShield(*4)。因為我們必須透過NT工作排程器,在夜間用腳本自動製作出安裝程式,由於WISE無法透過工作排程器半夜執行,因此就把它丟掉了(親切的WISE員工跟我保證,他們的最新版一定會支援夜間執行)。
3譯註:就好像考試收卷前的心態:再寫最後一題就好!
4譯註:這兩個都是用來製作安裝程式的工具。
3.你有進行每日編譯嗎?
在使用原始碼控制工具時,有時程式設計人員會不慎提交(check in)某些內容而導致編譯失敗。舉例來說,某人新增了一個原始檔,整個程式在他的機器上都能正常編譯,可是卻忘記把新增的原12個步驟始檔加到原始碼控制程式庫中。結果這位仁兄非常健忘且愉快地鎖上機器回家了,導致其他人無法做事,也只好很不爽地回家。
導致編譯失敗是非常糟糕的事情(又經常發生),這時每日編譯就很有幫助了,它能保證不會有漏網之魚。在大型的團隊中,要確保能立即修正編譯失敗的最佳方法就是每天下午(像是午餐時間)重新編譯。大家在午餐前盡可能的提交檔案,等大家用餐完畢編譯也已經完成。若結果顯示正常,很好!大家可以簽出最新版的原始碼繼續工作;如果有問題就將它搞定,而其他人還可以用前一版沒 問題的程式繼續幹活。
Excel團隊有個規定,導致編譯失敗的人必須從此負責重新編譯的動作當作處罰,直到有其他人出錯為止。這能讓大家盡量避免造成編譯失敗,同時也是個讓大家輪流熟悉重新編譯的好方法。在我的文章:「每日編譯是你的好朋友」裡有更多每日編譯的資料(*5)。
4. 你有沒有問題(bug)資料庫?
無論如何,只要你在寫程式時(只有一個人寫也是一樣),沒有一套良好的資料庫列出程式中所有的問題,就一定會產生出品質低劣的程式碼。很多程式設計人員自認能把問題清單記在腦子裡,才怪!我從來沒辦法一次記住超過二或三個問題,而且會在第二天早上,或是趕著出貨時把它們全部忘掉。你一定要正式地記錄問題。
問題資料庫可大可小。一個最簡單有用的問題資料庫必須包含每個問題的下列資料:
• 重現問題的完整步驟。
• 應該看到的行為。
• 實際看到的(有問題的)行為。
• 被指派的負責人。
• 是否已修正。
如果你是因為覺得問題追蹤軟體太複雜才不追蹤問題,請建立五欄的簡單表格,填入上述資料,然後開始使用吧!想要深入瞭解問題追蹤,請參閱「無痛錯誤追蹤」一文(*6)。
5 請參見第10章。
6參見www.joelonsoftware.com/articles/fog0000000029.html。
5.你會先把問題都修好之後,才寫新的程式嗎?
古早第一版的Microsoft Word for Windows被視為「死亡行軍」型的專案。進度一直處在落後的情況。整個團隊的工作時間長得離譜,專案卻一延再延三延,大家都承受無比的壓力。拖了幾年後,那個鬼東西終於上市了,微軟就把整個團隊送到Cancun(墨西哥著名海灘)渡假,然後再坐下來做深度反省。
他們發現產品經理過度堅持要維持「進度」,而程式設計人員只能匆匆經過編碼階段。而且正式的時程並未包含錯誤修正這個階段,於是寫出的程式碼非常糟糕。此外,也沒有人試圖要減少問題數量,而事實剛好相反!有位程式設計人員要寫支程式以計算一行文字的高度,結果他只寫了「return 12;」,並等問題報告出爐指出這個函數功能不對。於是,時程表變成一份等著被轉換成問題的功能列表,事後檢討時則稱之為「無窮錯誤法(Infinite defects methodology)」。
為了修正這個問題,微軟全面採用所謂的「零錯誤作法(Zero defects methodology)」。公司裡很多程式設計人員聽了都不禁竊笑,因為感覺就像是管理階層認為能用行政命令降低錯誤數量一樣。實際上,「零錯誤」是指無論何時都要先修正錯誤才能寫新程式。原因如下:
一般來說,愈晚修正錯誤,修正時所付出的成本(時間及金錢)愈高。舉例來說,當你打錯字或出現編譯器會發現的語法錯誤,就修正只是小事一樁。
若你的程式第一次執行出錯時,應該也能立即改正,因為整個程式還在你腦海裡。如果要為幾天前寫的程式除錯,應該需要回想一陣子吧!不過,當你重讀所寫的程式後,就會記起所有細節,並在適當時間內把問題修好。
若是要為幾個月前寫的程式除錯,那很有可能已經忘掉一大半,要修正簡直難上加難!或許,你正在替別人的程式除錯,而當事人遠在阿盧巴渡假,這時除錯的任務就像科學一樣:你得條理分明、小心翼翼地慢慢來,也無法確定要多久時間才能解決。另外,如果要為已出貨的程式除錯,修正問題的代價就更難以估算了!
這就是要立即修正問題的理由之一,因為這樣做能少花點時間。另一個理由是,寫新程式的時間遠比修正現有錯誤的時間容易估計。舉例來說,如果要你估計寫串列排序的程式需時多久,你應該能估算得相當準確;但假如你的程式在裝了 Internet Explorer 5.5之後有問題,要估計需要多久才能修好,恐怕用猜的都猜不出來,因為你不知道(當然不知道)問題點在哪裡。要找出問題可能就要花上三天,但也可能兩分鐘內解決。
如果時程裡包含很多有待修正的問題,那麼這種時程是不可靠的。假如把已知的錯誤都修好了,剩下的就只有新程式了,那麼時程就會變得非常準確。
把錯誤數量維持在零還有另外一項優點,就是面對競爭時反應可以更快。有些程式設計人員認為這樣做可讓產品隨時推出。一旦競爭者推出某個殺手級新功能來搶客戶時,只要把該功能加上去,即可立即出貨,不必修正累積下來的大量問題。
6.你有一份最新的時程表嗎?
在此要好好的談時程表。如果你的程式對公司非常重要,有太多理由可以說明,預知程式完成時間點有多麼重要。但程式設計人員是出了名的不愛訂定時程,他們會對著業務部門大吼:「該完成的時候就會完成了阿!」
但是問題不可能就這樣算了。業務人員有太多的規劃決策必須遠在程式出貨之前就做好決定,如:功能展示、商展、廣告等,而做決定的唯一方法就是定出時程,並且隨時更新。
擁有時程的另一個重點是,可以強迫自己決定要製作哪些功能,並剔除最不重要的功能,以避免功能過度膨脹(featuritis,又名 scope creep)(*7)。
其實,維護時程表並不困難。可參閱本書第9章,那裡會告訴你如何建立好用時程表的簡單方法。
7 featuritis的定義可參閱www.netmeg.net/jargon/terms/c/creeping_featuritis.html(譯註:原址失效,可以參閱http://en.wikipedia.org/wiki/Feature_creep)。
7.你有寫規格嗎?
寫規格就像是使用牙線:大家都同意這是好事,卻沒有人真的這麼做。
我不知道原因,或許是大多數程式設計人員都討厭寫文件吧!所以當全是程式設計人員的團隊面對問題時,自然傾向用程式碼而非文件來表示。他們寧願跳進去寫程式,死也不願先寫規格。
在設計階段發現問題時,只要改幾行文字就能輕易修正。但等到程式寫出來之後,修正的代價就高多了,代價包含了情感(人們討厭拋棄程式碼)和時間,所以會抗拒修正問題。通常未依據規格製作的軟體,到最後的設計都很糟,而且進度完全無法控制。這似乎就是Netscape所發生的問題。它的前四版一團亂,結果管理階層還愚蠢地決定把程式丟掉重新開始(*8)。然後在Mozilla上又重蹈覆轍,製造出一個無法控制的怪物,耗了好幾年才進入alpha測試階段。
8請參閱第24章。
我的小秘方是把程式設計人員送去上密集的寫作課程(*9),讓他們變得不那麼排斥寫作,就可以解決這個問題。另一個方法是雇用聰明的產品經理來寫規格。不管用哪一種方法,你都應該強制執行「沒有規格就不寫程式」這個簡單的規則。你可以由第 5章到第 8章學到所有關於規格的內容。
9如同耶魯大學的「 Daily Themes」課程( www.yale.edu/engl450b/),以要求學生每天寫一篇短文而聞名(譯註:原址已失效,可以在 http://www.yale.edu/english/undergraduate-courses.html找到相同課程)。
8.程式設計人員有沒有安靜的工作環境?
有大量的文件記載,為知識工作者提供空間安靜及隱私可以提昇產能。軟體管理經典著作《 Peopleware》也詳盡地記載了這種產能上的增益(*10)。
10由Tom DeMarco和Timothy Lister合著,《 Peopleware: Productive Projects and Teams(Second Edition)》(Dorset House Publishing, 1999)(譯註:本書有中文版,《Peopleware:腦力密集產業的人才管理之道,方亞瀾、錢一一譯,經濟新潮社》)。
其中的原理如下。我們都知道知識工作者進入「沉浸狀態」(flow,也稱作 in the zone)時,工作效果是最佳的。這時他們會完全與環境脫離,全心專注在工作上。他們忘記時間並絕對專注地產出極佳成果。他們所有豐富的產出也都是在這個時候完成的。作家、程式設計人員、科學家,甚至是籃球員都會告訴你進入「沉浸」的情形。
問題是要進入沉浸並不是那麼容易。你可以試著計時,平均大概要15分鐘才能開始全速工作。一旦碰到累了或是那一天已經有很多創造性的成果,會根本無法進入沉浸,然後就只能看看網頁、玩玩俄羅斯方塊打混過完一天。
另一個問題就是沉浸不容易維持。噪音、電話、同事的中斷(特別是這一點)都會讓你脫離沉浸。假設有個同事問了一個問題只讓你中斷了一分鐘,實際上,卻會讓你完全脫離沉浸,必須再等半個小時才能回復生產力,導致整體產能都出問題了。如果你身在一個喧鬧的開放辦公環境中(就像某些網路公司最愛的類型),行銷部門在程式設計人員旁一直對著電話大喊,那麼你的產能就像一直被中斷的知識工作者一樣顛簸,永遠無法進入理想的「沉浸」。
這對程式設計人員來說是非常嚴重的事情。生產力的多寡在於能否於短期記憶體中處理大量的細節,而任何一種中斷都會讓這些細節完全消失。等你轉回來工作時,就會完全不記得任何細節(例如,正在使用的區域變數名稱,或是搜尋演算法寫到哪了),必須把剛才寫的東西找出來,於是速度就這樣放慢下來,直到你回復為止。
以下做個簡單的計算。就用剛才的說法:打斷程式設計人員的一分鐘,事實上是耗費了15分鐘的產能。假設有兩個程式設計人員Jeff和Mutt,把他們安排在一個標準呆伯特式牛棚相鄰的開放隔間中。 Mutt忘了strcpy函數的Unicode版本拼法,他可以花30秒自己查出來,也可以花15秒問Jeff。由於對方就坐在旁邊,所以選擇問Jeff,於是Jeff就分心並損失了15分鐘的產能(但替Mutt省了15秒)。
現在把他們搬到兩間有牆有門的獨立房間裡。如果Mutt忘記那個函數的拼法,他可以花30秒查出來,也可以花45秒過去問Jeff(以典型程式設計人員的身材來說,要離開位置並不輕鬆),結果他就自己查了。於是Mutt損失30秒的產能,不過,卻替Jeff省下15分鐘!
9.你有沒有用市面上最好的工具?
用編譯式語言撰寫程式得花一些時間進行編譯,可說是一般家用電腦還無法瞬間完成的事情之一。如果你的編譯過程超過幾秒,去找台最新、最棒的電腦可以替你省點時間;如果編譯需要超過15 秒,程式設計人員覺得無聊就會跑去看線上新聞 The Onion(*11),然後陷在裡面耗掉幾個鐘頭的產能。
11 請參見http://www.theonion.com。
在單螢幕系統上替 GUI程式除錯並非絕不可能,但用起來很痛苦。當你在撰寫GUI程式時,或許使用兩台螢幕會讓你輕鬆許多。
大部分程式設計人員到最後都必須修飾圖示或工具列所用的圖,可是大部分的人都沒有一個好用的圖形編輯器。雖然用微軟的小畫家修圖實在令人不可思議,不過,卻是多數程式設計人員不得不做的事。
在我的前一家公司(*12),系統管理員會一直傳送自動發送的垃圾信給我,抱怨我在伺服器上使用了超過「 220 MB」的硬碟空間。依據現在硬碟的價格,這點空間的費用還遠不及我所用的衛生紙。即使只花10分鐘清理目錄,也是產能的極大浪費。
12參閱第32章。
一流的開發團隊並不會虐待他們的程式設計人員。工具不佳所引起的挫折感雖然很小,累積起來還是會讓程式設計人員心情超級不爽、外加脾氣暴躁。而心情不爽就等於是無生產力。
不過,程式設計人員也是很容易被酷炫、新潮的東西所賄賂,這比用加薪叫他們工作要便宜得多了!
10.你有沒有測試人員?
如果你的團隊沒有專門的測試人員(至少每兩到三個程式設計人員要配一名),就可能會推出問題很多的產品,不然就是浪費錢,像是讓時薪 100美元的程式設計人員去做測試員(時薪 30美元)做的事。省下測試員的錢並不是真正的節省,這是非常明顯的道理,但我實在很驚訝很多人卻還認不清這一點。我們將在第22章中會有更多的討論。
Chapter 03 約耳測試:邁向高品質程式碼的12個步驟2000年8月9日,星期三 你曾聽說過SEMA嗎(*1)?這是一套相當深奧的系統,可以測量軟體團隊的好壞。等一下!不要急著連過去看,我想光是要搞懂那個東西大概就要花上你六年的時間。所以我自己有一套無責任的簡易方法來衡量軟體團隊的品質,這套方法的好處是只要花3分鐘,省下的時間足夠讓你唸一趟醫學院。 約耳測試(Joel Test)1. 你有使用原始碼控制系統嗎?2. 你能用一個步驟建出所有結果嗎?3. 你有進行每日編譯嗎?4. 你有沒有問題資料庫?5. 你會先把問題都修好之後,才寫新的程式嗎?...
購物須知
關於二手書說明:
商品建檔資料為新書及二手書共用,因是二手商品,實際狀況可能已與建檔資料有差異,購買二手書時,請務必檢視商品書況、備註說明及書況影片,收到商品將以書況影片內呈現為準。若有差異時僅可提供退貨處理,無法換貨或再補寄。
商品版權法律說明:
TAAZE 單純提供網路二手書託售平台予消費者,並不涉入書本作者與原出版商間之任何糾紛;敬請各界鑒察。
退換貨說明:
二手書籍商品享有10天的商品猶豫期(含例假日)。若您欲辦理退貨,請於取得該商品10日內寄回。
二手影音商品(例如CD、DVD等),恕不提供10天猶豫期退貨。
二手商品無法提供換貨服務,僅能辦理退貨。如須退貨,請保持該商品及其附件的完整性(包含書籍封底之TAAZE物流條碼)。若退回商品無法回復原狀者,可能影響退換貨權利之行使或須負擔部分費用。
訂購本商品前請務必詳閱
退換貨原則、
二手CD、DVD退換貨說明。
本商品資料由TAAZE會員提供,TAAZE並已依據現貨及一般人之認知對其進行審核;TAAZE對其正確性不負連帶責任。若對商品資料有疑義請聯絡TAAZE客服。