邁向高質量的12個步驟

2019-11-18 13:13:00

字體：大中小

來源：轉載

供稿：網友

　　聽說過SEMA嗎? 這是一套相當深奧的系統, 可以測量軟件團隊的好壞. 等一下! 不要急著連過去看. 光是要搞懂那東西大概就要花上六年了. 所以我自己有一套無責任的簡易方法來衡量軟件團隊的質量. 這套方法的好處是只要花3分鐘左右. 省下的時間足夠讓你念趟醫學院.
　　
　　The Joel Test
　　
　　你有使用原始碼控制系統嗎?
　　你能用一個步驟建出所有結果嗎?
　　你有沒有天天都重新編譯建立(daily builds)嗎?
　　你有沒有問題追蹤數據庫(bug database)?
　　你會先把問題都修好之后才寫新的程序嗎?
　　你有一份最新的時程表嗎?
　　你有規格嗎?
　　程序人員有沒有安靜的工作環境?
　　你有沒有用市面上最好的工具?
　　你有沒有測試人員?
　　有沒有在面試時要求面試對象寫程序?
　　有沒有做走廊使用性(hallway usability)測試?
　　
　　
　　約耳測試 (Joel Test) 的好處是每個問題都很輕易回答是或否. 你不必計算天天寫的程序行數或是每個轉折點的平均問題數量. 只要答"是"就加1分. 約耳測試的缺點是絕對不能用來確保核電廠的安全性.
　　
　　得12分是完美, 11分勉強可接受, 不過10分以下(?0分)就表示問題大了. 事實上大部份軟件組織都只拿到2或3分, 這些組織都岌岌可危, 因為微軟隨時都是以12分的水平運作.
　　
　　當然啦, 這些并不是決定成敗的唯一因素: 非凡是當你的優秀團隊做些沒人要的產品時(對, 沒人要). 另外也可能有那種"高手"團隊, 即使完全不鳥這些東西卻還是能做出改變世界的夢幻軟件. 不過除此之外其它人都一樣, 假如你能把這12件事做好, 就能建立一個能穩定出貨的紀律團隊.
　　
　　1. 你有使用原始碼控制系統嗎?
　　我用過一些商用原始碼制系統也用過免費的CVS, 我可以告訴你CVS相當不錯. 不過假如你沒有原始碼控制系統, 當需要程序人員合作時你就會被壓垮了. 程序人員沒法子知道其它人做了些什么. 也不能輕易回復成出錯前的狀態. 原始碼控制系統還有另一個優點, 就是原始碼會被注銷(check out)到各個程序人員的硬盤里 -- 我還沒看過哪個用了原始碼控制的項目會遺失大量程序.
　　
　　2. 你能用一個步驟建出所有結果嗎?
　　我的意思是: 從最新的原始碼快照開始, 要花多少步驟才能建立出貨用的軟件? 好的團隊會有單個腳本檔案, 只要執行這個檔案, 就會從頭注銷所有檔案, 編譯每一行程序, 建立執行文件(包含所有不同版本,語言以及 #ifdef組合), 制作安裝程序, 并且產生出最后要用的媒體形式 -- 光盤片編排, 網站下載或是其它各種形式.
　　
　　假如這個程序不只一個步驟, 就會輕易出錯. 另外當出貨時程緊逼時, 修正"最后的"問題,制作最終執行檔等等的過程要能飛快地完成. 假如程序編譯和安裝文件制作等動作要20個步驟才能完成, 你一定會急瘋掉并且做出一些蠢事.
　　
　　就是為了這一點, 我前一家公司把原本用的WISE換成InstallShield: 我們需要能透過NT工作排程器, 在晚上用描述檔自動執行的安裝制作程序, 由于WISE不能透過工作排程器半夜執行, 所以我們就把它丟掉了. (親切的WISE員工跟我保證他們的最新版一定會支持夜間執行.)
　　
　　3. 你有沒有天天都重新編譯建立(daily builds)嗎?
　　在使用原始碼控制工具時, 有時候程序人員會不慎登入(check in)某些內容而導致編譯失敗. 舉例來說, 某人新增加了一個原始程序文件, 整個程序在他的機器上都能正常編譯, 可是卻忘記把新增的程序文件加到原始碼控制程序庫中. 結果這位仁兄健忘并快樂地鎖上機器回家了. 其它人都不能做事, 所以也只好很不爽地回家.
　　
　　導致編譯失敗非常糟糕(又經常發生), 這時天天重新編譯建立就很有幫助了. 它能保證不會有漏網之魚. 在大型的團隊中, 要確保能立即修正編譯失敗的最佳方法就是天天下午(像是午餐時間)重新編譯. 大家在午餐前盡可能的登入檔案. 等大家回來的時候已經編譯完畢. 假如結果正常, 很好! 大家可以注銷最新版的原始碼繼續工作. 假如有問題就去把它搞定, 而其它人還可以用前一版沒問題的程序繼續干活.
　　
　　我們Excel團隊有個規定, 導致編譯失敗的人必須從此負責重新編譯的動作(作為處罰), 一直到有其它人出錯為止. 這是個讓人不要導致編譯失敗的好誘因, 同時是個讓大家輪流處理重新編譯的好方法, 這樣大家都會知道怎么做.
　　
　　我這篇文章里有更多每日重新編譯的數據aily Builds are Your Friend.
　　
　　4. 你有沒有問題追蹤數據庫(bug database)?
　　不管你說什么. 只要你在寫程序(只有一個人寫也一樣), 假如沒有一套良好的數據庫列出程序中所有的問題, 一定會產生質量低劣的程序代碼. 很多程序人員自認能把問題清單記在腦里. 才怪. 我從來沒法子一次記住超過二或三個問題, 而且會在第二天早上或是趕著出貨時把它們全部忘掉. 你一定要正式的記錄問題.
　　
　　問題數據庫可大可小. 一個最簡化的有效問題數據庫必須包含每個問題的下列數據:
　　
　　重現問題的完整步驟
　　應該看到的行為
　　實際看到的(有問題的)行為
　　被指派的負責人
　　是否已修正
　　假如你是覺得問題追蹤軟件太復雜才不追蹤問題, 建個5欄的表, 填上這些重要字段然后開始用吧.
　　
　　想深入了解問題追蹤, 請參閱無痛錯誤追蹤.
　　
　　5. 你會先把問題都修好之后才寫新的程序嗎?
　　古早第一版的Microsoft Word for Windows 被視作為"死亡行軍"型項目. 進度一直落后. 整個團隊的工作時間長得離譜, 項目卻一延再延三延, 大家都承受到無比的壓力. 拖了幾年后那個鬼東西終于上市了, 微軟就把整個團隊送到Cancun (墨西哥聞名海灘) 渡假, 然后再坐下來做些深度反省.
　　
　　他們發現項目經理過度堅持要保持"進度", 結果程序人員只能趕工寫出爛程序, 而且正式的時程并沒有包含錯誤修正的階段. 沒有人試圖要減少問題數量. 而且實際上剛好相反. 有個程序人員要寫程序計算一行文字的高度, 結果他只寫了"return 12;" 并等問題報告出爐說這個函數功能不對. 時程表變成一份等著被轉換成問題的功能列表. 事后檢討時稱之為"無窮錯誤法".
　　
　　為了修正這個問題, 微軟全面采用所謂的"零錯誤作法". 很多公司里的程序人員都不禁竊笑, 因為聽起來像是治理階層認為能用行政命令降低錯誤數量. 實際上"零錯誤"是指無論何時都要先修正錯誤才能寫新程序. 原因如下.
　　
　　一般來說, 愈晚修正錯誤, 修正所付出的成本(時間及金錢)愈高.
　　
　　舉例來說, 當你打錯字或出現編譯器會發現的語法錯誤, 要修正只是小事一件.
　　
　　當你的程序第一次執行出錯時, 應該也能立即改正, 因為整個程序還在你腦海里.
　　
　　假如要為幾天前寫的程序除錯, 應該需要回想好一陣子, 不過當里重讀所寫的程序之后, 就會記起所有細節并在適當時間內把問題修好.
　　
　　不過假如你要為幾個月前寫的程序除錯, 很可能已經忘掉了一大半, 要修正就是難上加難. 你也可能正在替別人的程序除錯, 而當事人可能正在阿盧巴渡假, 這時候除錯就像科學一樣: 你得條理分明小心翼翼地慢慢來, 而且也無法確定要多久時間才能解決.
　　
　　另外假如要為已出貨的程序除錯, 要修正問題的代價可是難以估算的.
　　
　　要立即修正問題的理由之一, 就是因為這樣做能少花點時間. 另一個理由是寫新程序的時間比修正現有錯誤的時間較易估計. 舉例來說, 假如要你估計寫個串行排序的程序需要多久, 你應該能估算得相當準確. 不過假如說你的程序在裝了Internet EXPlorer 5.5之后有問題, 要估計需要多久才能修好這個問題, 恐怕你連猜都不會, 因為你不知道(當然不知道)問題哪兒來的. 要找出問題可能要花3天, 也可能只花2分鐘
　　
　　我的意思是假如你的計劃時程里有很多錯誤待修正, 這種時程是不太可靠的. 不過假如把已知的錯誤都修好了, 所剩的就只要新程序了, 那么你的時程就會變得非常準確.
　　
　　把錯誤數量維持在零還有另外一個優點, 就是面對競爭時反應更快. 有些程序人員認為這樣做能讓產品隨時能推出. 所以假如競爭者推出某個殺手級新功能來搶客戶, 你只要把那個功能加上去就可以立即出貨, 不必去修正累積下來的大量問題.
　　
　　6. 你有一份最新的時程表嗎?
　　我們在這里要談談時程表. 假如你的程序對公司非常重要, 有太多理由可以說明預知程序完成時點有多么重要. 程序人員不愛訂定時程可是惡名昭彰. 他們會對業務大叫: "該完成的時候就會完成!"
　　
　　但是問題不可能就這樣算了. 業務人員有太多的計劃決策必須遠在程序出貨之前做決定: 展示, 商展, 廣告等等. 而做決定的唯一方法就是定出時程并隨時更新.
　　
　　擁有時程的另一個重點是逼你決定要制作哪些功能, 并且能逼你剔除最不重要的功能而避免功能過度膨脹(featuritis, 又名scope creep).
　　
　　要維護時程表并不困難. 請參閱我的文章Painless Software Schedules, 文中敘述建立好用時程表的簡單方法.
　　
　　7. 你有規格嗎?
　　寫規格像用牙線: 大家都同意這是好事, 卻沒有人真的在做.
　　
　　我不知道為什么, 或許是因為大多數程序人員都討厭寫文件吧. 所以當全是程序人員的團體面對問題時, 自然傾向用程序代碼而非文件來表示答案. 他們寧愿跳進去寫程序也不愿先寫規格.
　　
　　在設計階段發現問題時, 只要改幾行就能輕易修正. 等程序寫出來之后, 修正的代價就高得多了, 代價包含了情感 (人們討厭塊棄程序代碼) 和時間, 所以會抗拒修正問題. 通常未依據規格制作的軟件最后的設計都很糟, 而且進度完全無法控制. 這似乎就是發生在Netscape上的問題. 它的前四版變得一團亂, 結果治理階層愚蠢地決定把程序丟掉重新開始. 然后他們在Mozilla

上一篇：軟件過程的發展的思考

下一篇：Debian下Mysql實踐