無痛功能規格 - 第一篇：何必麻煩呢？ Painless Functional Specifications – Part 1: Why Bother?

當約耳測試剛發表時，讀者反映說執行上最困難的一點就是寫規格。看起來規格就像用牙線：大家都知道應該要，卻沒有人真的在做。

為什麼大家不寫規格呢？有人聲稱跳過寫規格這個步驟可以節省時間。講得好像寫規格像是什麼奢侈品，只有 NASA 太空梭工程師或為大保險公司工作的人才能做。胡說八道。不寫規格是軟體專案中一個最大且不必要的風險。這就像只在背上掛件衣服就妄想飛越摩哈維沙漠一樣的愚惷。那些不訂規格直接寫程式的程式員和軟體工程師都會自認是神槍手，可以朝背後開槍。才怪。他們根本沒有生產力。他們寫出爛程式並做出低劣的產品，而且還讓專案承受完全可以避免的極大風險。

我認為所有重要的專案(寫程式時間超過一週或一個以上的程式員)都一樣，如果沒有規格，絕對會耗時更久並且寫出品質低劣的程式。理由如下。

規格最重要的功能是要設計程式。即使你是自己一個人寫好所有的程式，而且寫了規格也只是自己在看，寫規格這個動作(詳細描述程式運作)還是能迫使你實際設計程式。

讓我們看看分屬兩家公司的兩名虛構程式員。速食香蕉軟體的史快手從來不寫規格。「規格？我們才不要討厭的規格！」而好脾氣軟體公司的羅傑先生則在規格確定前絕對不寫程式。他們只是我眾多虛構朋友中的兩位。

史快手和羅傑先生有個相同點：他們都負責自家產品2.0版的向後相容事宜。

史快手決定，提供向後相容的最佳方法就是寫一個轉換器，把 1.0 版的檔案轉成 2.0 版檔案。她開始打程式，喀嗒喀嗒，硬碟轉呀轉，雞飛狗跳。大約兩週後弄出一個還不錯的轉換器。不過史快手的客戶不太高興。史快手的程式等於強迫全公司一次昇級成新版本。史快手最大的客戶 Nanner Splits 無限公司拒絕購買新軟體。他們要確定 2.0 版軟體能不經轉換使用1.0版檔案。史快手決定寫一個回溯轉換器並掛在「存檔」功能內。這就有點複雜了，在使用 2.0 版的功能時似乎一切正常，不過等要把檔案存成 1.0 格式時就有問題了。你會發現前半小時用的新功能都無法以舊的檔案格式儲存。所以回溯轉換器又寫了兩週，而且也不是很好用。這樣子4週就過去了

而好脾氣軟體公司的羅傑先生是那種一切照規矩的人，沒拿到規格前是絕對不寫程式的。他花了 20 分鐘設計出和史快手一樣的向後相容功能，並且寫出大意如下的規格：

• 如果開啟的檔案是由舊版產品所建立的，就把檔案轉成新格式。

把規格先拿給客戶看看，客戶說話了「等一下！我們不想讓全公司都昇級！」所以羅傑先生再想想後把規格改成：

• 如果開啟的檔案是由舊版產品所建立的，就把檔案在記憶體內轉成新格式。等要儲存這個檔案時，使用者可以選擇存回舊格式。

這樣又用了20分鐘。

羅傑先生的老闆是個物件導向狂。他看看這份規格，覺得有點問題並且建議用另一種架構。

• 把程式重組成使用兩組介面：V1和V2。V1包含所有版本一的功能，而V2則是繼承V1並加上所有新功能。這樣V1::Save可以處理向後相容事宜而V2::Save可以儲存所有新東西。如果你開啟V1檔案後使用到V2的功能，程式可以馬上警告你，你必須轉換成新檔案格式或放棄使用新功能。

又20分鐘去了。

羅傑先生不太高興。因為重組程式要花3週而不是他原先估的2週！不過的確優雅地解決了客戶所有的問題，所以他還是回去照做了。

羅傑先生所花的時間總共是3週加1小時。史快手則花了4週，不過史快手的程式沒那麼好。

這個故事告訴我們，只要舉的例子夠怪，什麼事都可以證明。對不起，剛才是開玩笑的，我不是這個意思。這個故事真正要說的是，當你以人用的語言設計產品時，只需要花幾分鐘就能考慮多種可能並且修訂及改進自己的設計。沒有人會覺得在文書處理器裡刪掉一段有啥大不了的。不過當你用程式語言設計產品時，反覆設計就得花上好幾週了。更糟糕的是，某段程式可能只花程式員2週就寫出來，可是他會一直死抱著那段程式，不管程式錯得多麼離譜。雖然史快手的程式並非最佳的架構，可是不管她老闆或客戶說什麼，都無法說服她把那段漂亮的轉換程式丟掉。結果最終的產品很容易變成最初設計和錯誤設計以及理想設計間的妥協。它是「我們所能做到的最佳設計，因為這些程式都寫好了，而我們又捨不得把寫好的程式丟掉重寫」。如果光是「我們所能做到的最佳設計」，沒有後面那些廢話會更好。

所以這就是寫規格的天字第一號理由。天字第二號是節省溝通時間。當你有寫規格時，對於程式應有的作用只需要講解一次。團隊裡其他人只要讀規格就好了。品保人員讀了規格就知道程式的動作同時也知道如何測試。行銷人員讀了規格就能寫出曖昧的資料，放在網站上宣傳尚未出現的產品。事業開發人員沒好好讀規格卻在幻想，以為產品能治療禿頭腫瘤還有毒癮，不過這樣能吸引投資者，所以沒啥關係。開發人員讀了規格就知道要怎樣寫程式。客戶讀規格則是要確定開發人員正在製作他們想買的產品。技術作者讀了規格才能寫出好的手冊(然後被遺失或丟掉，不過這是另一個故事。經理也讀規格，才能讓自己好像知道經營會議的內容。如此類推。

這所有的溝通在沒有規格時還是會發生，因為這都是必要的，不過這時的溝通都是特別安排的。品保人員無論如何都得玩這個程式，看到有任何不對勁就會再度中斷程式人員，並且問另一個程式應該怎麼動的蠢問題。這不只會毀掉程式人員的生產力，而且程式人員也習慣照自己程式的寫法回答問題，而不會回答「正確的答案」。結果品保人員實際上是用程式來檢驗程式，而非以設計來檢驗程式，而後者應該會好一點吧。

當你沒有規格時，可憐的技術作者會遇到很好笑的事(以極悲慘的方式)。技術作者通常沒有中斷程式人員的特權。在很多公司中，如果技術作者習慣中斷程式人員問些程式運作上的問題，程式人員會找經理告狀，說這些該死的作者讓他們什麼事都做不了，請他們閃遠一點。經理為了想提升生產力，就禁止技術作者不要再浪費程式人員寶貴的時間。這種公司很容易分辨，因為它們的說明檔和手冊裡講的沒比畫面上多多少。當你在畫面上看到以下的訊息

• 你要啟動LRF-1914支援嗎？

...當你點選「說明」就會看到一段叫人哭笑不得的內容

• 允許你選擇LRF-1914支援(預設值)或無LRF-1914支援。如果你需要LRF-1914支援，點選「是」或按「Y」。如果不需要LRF-1914支援，點選「否」或按「N」。

嗯，謝了。很顯然技術作者試圖掩飾他們不知道LRF-1914支援是啥的事實。他們不能問程式人員，因為(a)他們太害羞了，或是(b)程式人員在海得拉巴(印度)而他們在倫敦，或者(c)管理階層禁止他們中斷程式人員或是其他各種數不清的企業弊病，不過根本的問題在於沒有規格。

寫規格的天字第三號理由就是沒有詳細規格就無法訂出時程。有些場合沒有時程是可以的，例如你打算花 14 年研究的博士論文，或打算寫下一版等好了就會推出的毀滅公爵遊戲。不過幾乎所有真實的事業都必須知道事情需要多久完成，因為開發產品是要花錢的。你不可能不知道價錢就買牛仔褲，那麼一個負責的企業怎麼能不知道要多少還有要多少錢，就決定是否製作某個產品呢？想多瞭解時程安排，請參考無痛軟體時程。

有個很糟糕的常見錯誤，就是對某個項目的設計爭論不休，結果永遠無法排除爭議。Windows 2000 的首度開發人員 Brian Valentine 就有句名言「10分鐘內給你決定，否則下一個免費」(譯註：美國著名的披薩連鎖店達美樂有一句廣告標語「30分鐘內送達，否則下一個免費」。同樣的，Brian會在10分鐘內決定，否則會免費給你下一個決定，不過要老闆下決定本來就不用付錢給你的，不是嗎？)

在很多的程式開發組織中，每次出現設計爭議總是沒有人願意作出決策(通常都是因為政治理由)。所以程式人員只去做那些沒有爭議的項目。等時間消逝而所有困難的決定都會壓到最後才決定。這些專案很可能會失敗。如果你針對某項新技術開了家新公司，卻注意到公司有結構性問題無法作出決策，你最好關門大吉把錢退還給投資者。因為你永遠都無法推出產品。

寫規格是處理這些煩人設計決策的好方法，這些問題有大有小，不過沒寫規格就看不到。即使很小的決策問題也可以寫規格搞定。舉例來說，如果你正在建一個會員網站，你們可能都會同意，當使用者忘記密碼時應該發信告知密碼。很好，不過對寫程式來說還不夠。要把程式寫出來得知道郵件中實際使用的文句。大部份公司都不認為程式人員能撰寫使用者實際接觸的文句(而且通常都有很好的理由)。所以會要求行銷人員或公關或是其他文學素養好的人決定訊息的文句內容。「王大明先生，這是閣下忘記的密碼。希望閣下往後能小心一點。」當你強迫自己寫出一份良好而完整的規格時(我很快就會詳述這一點)，就會注意到這所有的項目並且把它解決，或者至少標示出來以便修正。

好了。我們現在應該都能同意。規格是一切的根本。我懷疑大部份的人是否懂這一點，另外我講的雖然有趣，卻不知是否真能讓你學到新東西。那麼為什麼人們不寫規格呢？絕不是省時間，因為根本不會省，而且我認為大多數程式員都知道(在大部份組織中，唯一存在的「規格」都是斷簡殘篇，是程式員寫好程式後解說某該死功能第三百遍後，用記事本打出來的一頁文字文件。

我認為真正原因是多數人都不喜歡寫東西。瞪著空白的螢幕會讓人感覺極度地沮喪。我個人克服寫作恐懼的方法是去學校參加寫作課，一星期寫3到5頁的短文。寫作就像肌肉一樣，寫得愈多就愈能寫。如果你必須寫規格又寫不出來，開個期刊定訊，建一個 weblog，上個創作寫作課程，或是寫封信給親戚或四年未聯絡的大學室友。任何把文字填到紙上的活動都能增進你寫規格的技巧。如果你是個軟體開發經理而該寫規格的人寫不出來，把他送到山裡面上兩週創作寫作課吧。

如果你未曾在一家有寫功能規格的公司做過，可能會沒看過功能規格。我會在本系列的下一篇中展示一篇簡短的規格範例供你參考，另外我們也會討論一份好的規格必須具備的元素。繼續看！

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.