Common Lisp專家Peter Seibel對Google公司首席Java架構師Joshua Bloch的訪談(摘一段)

API對設計流程的影響

　　Seibel：你設計軟體的流程是什麼樣的?開啟Emacs就開始寫代碼，然後改來改去直到程式寫好?還是坐到沙發上拿著一打紙先列個提綱?

　　Bloch：很多年前，我在OOPSLA(譯者註：物件導向編程、系統、語言和應用國際研討會。)上作了一個演講，題目是“如何設計一個好的API，以及這為什麼很重要”。網上可以找到這個演講的幾個版本。它很好地解釋了我的設計流程。

　　最重要的是瞭解你到底要設計什麼，也就是你要解決的是什麼問題。需求分析的重要性怎麼強調也不過分。有人認為：“噢，需求分析呀。跑到顧客那邊問問他需要什麼。得到客戶的答案不就成了嘛。”

　　事實絕非如此。這不僅是一個協商的過程，而且是一個理解的過程。許多顧客不會告訴你問題，而會告訴你一個解決方案。例如，顧客可能會說：“我需要你給這個系統加上以下17個特性。”那麼你必須問：“為什麼?你想用這個系統做什麼?你期望它怎麼發展?”等等。你要來來回回好幾次，直到弄明白顧客真正需要軟體去做的所有事情。這些就是用例。

　　這個階段最重要的事情就是提出好的用例。一旦有了用例，你就有了用來比較所有備選解決方案優劣的基準。你可以花大量的時間去改進用例，因為一旦用例錯了，你就徹底失敗了，所有後續的流程都會徒勞無功。

　　我見過這樣的事。有人找來一幫聰明人，還沒搞清到底要做個什麼樣的系統，就開工了。辛苦地工作了6個月，寫出來247頁的系統規範檔案。這是最糟糕的情況。因為6個月後他們精確制定出來的系統可能毫無用處。他們往往會說：“我們已經投資了那麼多，制定出來規範檔案，我們必須把這個系統做出來。”所以他們創造了一個沒有任何用處的系統，這個系統也從未投入使用過。多恐怖啊。如果沒有用例就做好了軟體，那麼當你試圖做點非常簡單的操作時就會發現：“哦，我的天，像選擇一個XML文檔並列印這麼簡單的事情，需要這麼多的代碼啊。”這是很恐怖的。

　　所以先擷取這些用例，然後編寫骨架API。骨架API應該很短很短，也就一頁紙的內容吧，一般正好是一頁，無需非常精確。你要聲明包、類和方法，如果還不清楚他們應該是什麼樣的話，可以放一句話的描述。不過這不是產品發布要求的那種品質文檔。

　　中心思想就是在這個階段保持敏捷，逐步完善API，使其滿足用例，為原始的API添加代碼，看是否可以滿足需求。真是不可思議，很多事情事後看真是太淺顯了，但設計API的時候，甚至是構思用例時，你還是會犯各種錯誤。用代碼實現用例時你會說：“哦，我的天，全都錯了。類太多了。這些可以合并，這些需要拆開。”或者類似這樣的話。好在API文檔只有一頁長，改起來也很容易。

　　你對API越來越有信心，代碼也就越寫越長。但是，核心原則是，先寫使用API的代碼，然後再寫實現它們的代碼。因為，如果實現代碼被廢棄，之前的工作就都白做了。事實上，應該在給出設計規範前寫API的代碼，否則你可能把時間浪費在給最後完全不需要的東西設計規範上。這就是我設計軟體的方法。

　　Seibel：設計Java集合類這樣的，一個具體的自包含的API，設計規範需要有多具體?

　　Bloch：我敢說比你想的要粗略多了。任何複雜的編程都需要API設計，因為大程式都需要模組化，你必須設計模組之間的介面。

　　優秀的程式員把問題分塊，孤立地去看他們。這樣做的理由有幾條。比如，你可能會在無意中創造出好用的、可重用的模組。如果你寫一個單一的系統，它越來越大，等你想分塊的時候，就無法找到清晰的邊界，最後系統就變成了一個無法維護的垃圾。所以我斷言，無論你是否把自己看成API設計者，把問題分塊都是最好的編程方法。

　　這就是說，編程的世界非常廣闊。如果對你來說編程就是寫HTML代碼，那麼這也許不是最好的編程方法。但是，我認為對於大多數編程來說，這就是最好的方法。

　　Seibel：所以你希望系統由不同的模組鬆散地耦合在一起。要達到這樣的目標，現在有兩種不同的看法。一種是坐下來實現設計模組間的API，像你前面提到的那樣。另外一種是，“構建可啟動並執行最簡系統，然後毫不留情地重構”。

　　Bloch：我不認為這兩種方法有什麼衝突。某種程度上，我談的就是測試先行編程，以及對API的重構。如何測試你的API呢?在實現API之前編寫它的測試案例。雖然我還不能運行用例，但我在進行測試先行的編程：實現用例後看API是否能完成任務，我用這樣的方法測試API的品質。

Seibel：也就是說你寫好使用API的使用者代碼，然後評審代碼：“這就是我要的代碼嗎?”

　　Bloch：對!有時候你都不用走到評審使用者代碼的這個階段。寫代碼的時候可能就會有感悟，“寫不出來，我忘了這部分API的功能了。”或者“這代碼寫起來太乏味了，一定哪裡出錯了。”

　　這跟你多麼優秀無關。不用API寫代碼，就不可能看出API有什麼問題。設計了一個東西，使用了才知道：“哦，錯的這麼離譜。”如果這是在你浪費大量時間基於這個API寫了無數代碼之前的話，那麼這就是一個重大的勝利。所以，我談得更多的是測試先行編程和對API的重構，而不是重構API的實現代碼。

　　說到能夠啟動並執行最簡程式，我完全贊同這種提法。API設計有一條基本原則：疑則不用。它必須是完全滿足你關心的所有用例的最簡系統。而不是說“把亂七八糟的代碼堆在一起”。有很多格言警句說明了這點。我最喜歡的一條是：“簡單沒那麼容易做到。”坊間認為就是Thelonious Monk說的，實際不是，是誤傳。

　　沒人喜歡爛軟體。人們提倡“構建可啟動並執行最簡系統，然後毫不留情地重構”，而不提倡“寫垃圾代碼”，更不會說“不要做前期設計”。我曾跟Martin Fowler討論過這個問題。他堅信，只有仔細推敲要做的東西，系統才會有合理的形狀和結構。他說過，“不要在寫代碼前先寫下247頁的設計規範。”我很贊同。

　　我不贊同Martin的一點是：我認為測試不能用來取代文檔。只要你寫了別人編程時可以利用的代碼，你就需要做出精確的說明，而測試確保這些代碼符合你給出的說明。

　　所以兩大陣營確實有些不同意見，但是我認為他們之間的鴻溝沒有某些人想象的那麼大。

　　Seibel：既然你提到了Fowler，咱們就聊聊他。他寫了很多關於UML的書，你把UML當設計工具用過嗎?

　　Bloch：沒有。我覺得用UML做些圖表讓其他人理解起來可能更容易。但是說實話，我根本記不住那些組件應該是方的還是圓的。