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