為什么“開發(fā)人員友好性”是API設(shè)計的核心
Douglass C. Smith 教授在 2006 年 IEEE 的報告中指出：后者的進程和發(fā)展將超越具體算法語言的發(fā)展。實際上是，開發(fā)人員也應(yīng)該注意到這一點了：開發(fā)過程中的阻礙從學習算法和數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換到了選擇，學習和使用層出不窮的 API 上。但是很多程序員沒有意識到 API 的優(yōu)劣所導致的區(qū)別，以及為此需要設(shè)計好的 API 所要付出的努力。
微軟在 API 設(shè)計上是很費心血的，這種努力和專注始于上世紀 80 年代 Windows 的誕生。他們理解一個平臺的成功取決于這個平臺所能吸引和擁有的開發(fā)者(Steve Ballmer 的視頻 ”developers,developers,developers” )。 .Net 的***架構(gòu)師 Krzysztof Cwalina 出了一本專門《.NET 設(shè)計規(guī)范:約定、慣用法與模式》 指導開發(fā)人員。相似的，Sun(Oracle)也有相關(guān)的 Java SDK 的書籍。在一次采訪中，Sun 的前任***架構(gòu)師，Joshua Bloch (現(xiàn)任職 Google)洋洋灑灑地總結(jié)了 19 頁 Sun 在 API 設(shè)計上的理念。同樣的，SAP 雇傭了 Carnegie Mellon 大學的研究人員具體研發(fā)新的網(wǎng)絡(luò)服務(wù)接口(web services interfaces)。這些業(yè)內(nèi)大佬們的實例無不給了我們一個信號，API 設(shè)計在推動軟件使用和程序開發(fā)中的價值。
譯者注：本文通過學術(shù)統(tǒng)計報告理論上證實 API 質(zhì)量的重要性，循序漸進地例證：API 的優(yōu)劣如何評判，API 的改進能多大程度地提高編程效率，以及為什么我們需要一個對開發(fā)人員友好(Developer-Friendly)的 API。然后概括例舉了優(yōu)質(zhì) API 的特性，以及如何在實際操作中實現(xiàn)這些特性。
我們的主張
如果說書籍是以封皮判斷，那么軟件平臺、服務(wù)、架構(gòu)和庫是由它們的 API 定義的。當開發(fā)人員評價一個 API 的時候，他們實際上是對 API 所有的服務(wù)和包裹進行評價。API 設(shè)計是很聰明的投資，你得到的回報是忠實的開發(fā)人員。
研發(fā)人員和機構(gòu)越來越意識到 API 質(zhì)量的好壞直接影響到自己代碼的質(zhì)量。雖然將他人代碼質(zhì)量的好壞視為 API 作者的責任有些奇怪，但 API 質(zhì)量影響到使用 API 代碼質(zhì)量的例子卻越來越多。盡管使用復(fù)制黏貼，樣板等類似的編程方法被視為是缺乏編程技能，但是即便是最出色的程序員(在使用 API 的時候)也無法避免使用這樣的編程方式除非自己用代碼重新包裝 API。不難看出每個研發(fā)人員用代碼包裝 API 都是在填補 API 天生的不足之處。因為 API 一旦出爐將被反復(fù)使用，所以越來越多的研發(fā)人員希望 API 的作者能填補 API 的天生不足。在有眾多的開放式網(wǎng)絡(luò)服務(wù)和免費開源組件可以選擇的時代，研發(fā)人員默默的使用有天生不足 API 的日子已經(jīng)一去不復(fù)返了。
為使 API 更加易學，易用，易除錯作出的任何努力都可以直接提高使用 API 的程序員的效率。讓我們回頭看看開篇的主題：當今，研發(fā)人員將大量的時間花費在學習 API，使用 API 和代碼調(diào)試上，這些活動都是在通過包裹在多個復(fù)雜的 API 來實現(xiàn)一個業(yè)務(wù)邏輯。所以，更好的 API 會使研發(fā)人員有更高的效率。很多學術(shù)數(shù)據(jù)可以證實 API 的設(shè)計質(zhì)量直接聯(lián)系到編程的實際效率。2007的一份研究報道的數(shù)據(jù)表明 API 上哪怕是細微的變化，例如使用構(gòu)造函數(shù)(constructor)取代工廠方法(factory methods)也可以大幅度地提高程序員的編程效率。他們的數(shù)據(jù)顯示，使用 constructor，不管程序員的經(jīng)驗、技術(shù)的區(qū)別，他們大多能在同樣短的時間內(nèi)完成;而使用 factory methods，程序員們所需要的時間可以相差 10 倍。也就是說 factory methods 的 API 很打程度上取決于使用者。而取決于個人的工具不是一個好工具。相似的報道顯示了編程效率可以相差 10 倍如果一個方法被放到不同的 class 里面。
很多時候在 API 軟件不能很好地被使用的情況下，程序員會被指責太自我，或者恐懼新事物，不確定，疑惑(FUD)。但是實際情況是，API 的質(zhì)量不夠好才是主導因素。常見的問題是 API 的文檔不夠清晰明了;API 的方法太情景鎖定(specific to scenario);API 有太多 Dependencies，與其使用它，還不如自己寫來地快。我們可以得出結(jié)論，只要 API 的質(zhì)量不得到提高，軟件的采用率也就不會上升。
什么是好的 API
什么是好的 API?什么是程序員需要的?API 需要什么質(zhì)量去吸引程序員?我們的設(shè)計努力應(yīng)該付出在哪里?
***點：intuitive: 直觀
什么是直觀的?具體又如何實現(xiàn)?Wikipedia 上解釋直觀(intuitive)“不需要刻意努力的理解”(understanding without apparent effort)，Merriam Webster 的解釋是“不需要刻意有理推導來獲取知識或者認識的力量”(“the power or faculty of attaining to direct knowledge or cognition without evident rational thought and inference”)。細說開去，我們可以用一個博士學位來討論人類的認知過程，我們就不展開了。就 API 設(shè)計來講，intuitive design 就是站在使用者的角度，保持邏輯一致。
第二點，simple: 簡潔
這個會在以后的博文里面具體展開。這里我們就說一個綱領(lǐng)：需要平衡復(fù)雜的功能和簡單的用戶界面。
第三點是 easy to understand, remember, and use 易于理解、記憶和使用
這是任何專家都會給出的建議，但是實際操作卻很難自始至終做到這點。盡量使用程序員們熟悉的邏輯和概念，用他們的語言(邏輯和語法)和他們對話，盡量減少引進新的概念和規(guī)則。尊重他們熟悉的命名方式，這樣可以幫助他們記憶。這些減少刻意學習和使用的設(shè)計理念在 API 設(shè)計中很重要，因為它直接決定了開發(fā)人員適應(yīng) API 的速度和程度。
簡單適用：程序員沒有太多時間去評估一個 API 的好壞去決定是否使用。大多數(shù)時候，我們就試用兩個方法，看看好不好用。API 設(shè)計應(yīng)該鼓勵試用：核心情景必須能被簡單采用，而且要有實例(sample code)來幫助采用。其二，API 要安全(safe)。這個包括兩點，一是本身那個情景(scenario)要穩(wěn)定。其次，如果出現(xiàn)問題，錯誤報告要全面、明確。
***一點：documented 文檔備案。
拿到新的 API，我們程序員會直接動手，而不是讀說明書。如果沒有人讀，APIs 到底需要文檔嗎?動手是淺嘗輒止，我們叫了個方法，然后它做了意料之中的事情，至于它有可能會出現(xiàn)什么問題，然后有什么解決方法，或者同樣的事情，是否有更加有效的方法完成，一行程序是不能了解的。這個就是為什么我們需要文檔，全方位、多角度的解釋(Redundancy)，不是簡單的重復(fù)同一種內(nèi)容(repetition)。
特定功能性 API (purpose-made APIs)
好的 API 是設(shè)計出來的。以上所列舉的 API 的特性和優(yōu)點不會自然流露在程序里面，把一組能被重復(fù)使用的獨立函數(shù)放在一起不是一個好的 API。軟件與軟件之間的界面會在獨立板塊的結(jié)界出現(xiàn)，但是這些界面如果不是結(jié)構(gòu)上設(shè)計好的，他們放在一起不會是好的 API。這個不是因為程序員的個人技術(shù)好壞，而是實際操作過程中容易迷失全景的概念。并且這樣生成的 API 很難維護，每次更新或者改錯都會引出新的問題。Erich Gamma 說過“好的 API 不會是偶然的發(fā)生，而是刻意的出現(xiàn)。他們是一筆巨大的投資”。API 設(shè)計應(yīng)該作為一個單獨任務(wù)，從實際寫程序的過程中獨立出來。設(shè)計出來的 APIs 是 purpose-made APIs. 他們應(yīng)該包括文檔備案(documentation)，實例(code samples)，教程(tutorials)和單元測試(unit tests)。他們鼓勵不同的采用方式，支持快速有效的用戶端，如此才能與時俱進。
***，正如 Joshua Bloch 所說：“公共 API，就像鉆石，恒久美，永流傳。你只有一個機會去把她做好，請竭盡全力。”
(“Public APIs, like diamonds, are forever. You have one chance to get it right so give it your best”.)
原文：http://blog.jobbole.com/10197/
【編輯推薦】
