# 五、輕松寫就功能規格說明書 - 第1節：為什么煩心？ 當約耳試驗剛發表時，讀者反映說執行上最困難的一點就是寫規格.看起來規格 就像用牙線：大家都知道應該要，卻沒有人真的在做. 為什么大家不寫規格呢?有人聲稱跳過寫規格這個步驟可以節省時間.講得好像 寫規格像是什么奢侈品，只有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，上個創作寫作課程，或是寫封信給親戚或四年未 聯絡的大學室友.任何把文字填到紙上的活動都能增進你寫規格的技巧.如果你 是個軟件開發經理而該寫規格的人寫不出來，把他送到山里面上兩周創作寫作 課吧. 如果你未曾在一家有寫功能規格的公司做過，可能會沒看過功能規格.我會在 本系列的下一篇中展示一篇簡短的規格范例供你參考，另外我們也會討論一份 好的規格必須具備的元素.