什麼是好的API設計？

摘要：有人言，api設計是程式設計工作中最難的事情。甚至有人認為至少要有10年的工作經驗才能接觸它。不過這裡提出了乙個引人思考的問題：究竟是構建什麼樣的庫需要花費10年的時間去學習？

有人言，api設計是程式設計工作中最難的事情。甚至有人認為至少要有10年的工作經驗才能接觸它。其實通過好的培訓或導師學習這個進度可以縮短很多，也有這樣或那樣的時候，一些沒有經驗的程式設計師卻設計出好的api。不過這裡引發出乙個問題：「究竟是構建什麼樣的庫需要花費10年的學習時間？」

在走出校門後，我很幸運地加入到atalasoft公司，這是一家生產設計api的公司。在這裡我受到了嚴格的訓練。我的導師steve hawley是乙個喜歡把大部分時間都花費在研究各種困難問題上的人，並且他會把這些問題壓縮到乙個非常精美的包裡。steve沒有太多的耐心教他的下屬，他愛好燒錄光碟，在這樣的環境下，雖沒達到青出於藍而勝於藍的地步，但卻讓我學到很多。

在他的價值觀裡是沒有清晰明確的宣告或者條條框框的東西，我稱為90-9-0.9。他希望90%的人僅通過剪下和貼上幾行**就可以解決常規問題。下面9%的目標是用來進行簡單地配置，通過檢視文件以及技術支援來解決問題，甚至有些問題在幾分鐘內就可以解決。0.9%的人會用各種亂七八糟的方式來扭曲你開發的庫，有時是因為效能原因，有時卻是利用其他一些你意想不到的古怪（但可執行）手段。為客戶的需求犧牲0.9%是完全正常的，只要保證客戶需求可以實現且文件按照要求顯示出來。

最後，還有1%的人會誤解你的產品能力，這些人會讓你非常不高興。忽視還是重視？最好做個市場調查，看看他們的是否值得你去擴充套件庫且讓他們成為其中的一員。

atalasoft的條形碼產品是乙個很好的例子，在產品上花很多精力去仔細調優和預處理，掃瞄許多文件且沒有發現問題。預處理後，在許可證允許的前提下缺省會全力嘗試各種型別的條形碼。這已經相當快了，在這麼短的時間裡可以給任何人進行掃瞄操作。儘管有時候會借助一些昂貴的裝置給使用者進行大規模批量化掃瞄，但速度還是不夠理想，所以掃瞄者可以修改乙個簡單的列舉屬性進行配置。偶爾有些掃瞄的確很困難，比如掃瞄乙個帶有條形碼的香蕉。對於這樣的事情，可能會讓你中斷乃至更換條形碼引擎。但是誰會拿著這樣的產品去讀狗身上剃出來的條形碼呢？如果你是這樣的人，建議你去尋找其他產品用吧！

第一次看到這種情況的時候，我認為這樣的設計真糟糕。整個元件就像乙個非常不統一且基於diy（do-it-yourself）事件的外掛程式系統。雖然如你所見，atalasoft不會為一名架構太空飛行員的美感進行優化，他們會為減輕客戶支援負擔而進行不斷調優。正如我不喜歡用物件導向的思想來編寫內部庫一樣，在開放乙個所有級別都能操作的簡單介面上，我認為沒有比這更好的正規化。

在過去的兩年裡，我一直在bayard rock公司負責api方面的工作，我們一直在研發一些反洗錢方面的專案。這意味著會做許多小型或中型實驗專案並且在以後會被整合到同行大的平台上。在大多數情況下，atalasoft風格的黑色裝箱（black-boxing）是起不到任何作用的。我們只有乙個客戶並且我們會根據他們的需求調整我們的外部api。

然而，在乙個細粒度級別中**重用是非常重要的，在這種情況下，最重要的是構建大型庫，即把許多分類函式快速的組合在一起（通過簡單的組合和沒有全面的單元測試），目前，我們正在進行優化實驗並且快速發展我們的元件。

那麼，什麼是好的api設計？其實，正如steve所言，沒有什麼清晰明確的框架可套，也更沒有什麼捷徑可走。我們既需要按照常規來進行設計，還需要綜合客戶要求將我們的設計理念融入進去，當然，得預防那些像掃瞄香蕉那樣稀奇古怪的事情的發生。或許這就是為什麼它會如此困難？我們也曾發表過《設計公共api的六個注意事項》文中作者根據自己的親身經驗總結了幾條api設計注意事項，大家不妨一起品嚐下！

來自：richardminerich

什麼是好的API設計？

什麼是好的API設計？

什麼是好的 API 設計？ eolink翻譯

好的API設計

相關推薦