開發人員：建構API時先自己試試

簡單地建構一個api是不夠的。如果在釋出api之前不能“先自己試試”，那麼結局就是失敗。zachary flower詳細解釋了個中原因。創業公司的開發生命周期必然充滿妥協。有太多東西需要完成，但是沒有足夠的資源保證所有東西都“正确”完成，是以開發人員在恰當的時候必須妥協。不幸的是，為産品建構api與其說是技術決策，不如定義成業務決策更為貼切，這也正是需要妥協的地方。

為已有産品建構api的挑戰是，業務需求總是最重要的。為了跟上業務需求的腳步，我們通常被強迫在産品品質上作出讓步，這在創業公司應用開發過程中很常見，也絕對是api開發的最差方式。

開發api時最重要的一件事是就是使用它。“dogfooding”是創業論壇裡的流行詞彙，用來描述企業規律地使用自己的産品，進而更好服務客戶的行為。在建立api時，能夠“先自己試試”極其重要，因為其向開發人員提供了一種方式來內建業務的核心功能到自己的産品裡。如果這樣，或者作為主要産品的一部分，api無法正常工作，那麼開發人員，及其使用者，注定無法獲得良好的使用者體驗。這會讓所有人都感覺很糟糕。

挑戰代碼基

如果在建構api時不先自己試試，那麼可能最終需要管理兩個單獨的，大部分功能一樣的代碼基。第一個代碼基，主要産品，是大部分開發活動發生的地方。是以，它比第二個代碼基，api，更加清晰并且功能更為豐富。

被稱為“第二個”代碼基的api，會很快成為無主代碼。它的更新很繁瑣，和實際開發相比更像資料處理的工作，因為大部分工作是從“主要”代碼基裡拷貝方法出來。因為其特性和bug修複晚于主要産品，這會使得使用者——至少堅持在使用的消費者——感到上當受騙，甚至可能感到被開發人員背叛了。

api開發會最終延期，甚至可能完全終止，進而保證團隊将更多的資源關注于主要産品上。

正确還是完全不正确

當建構api時，一個很好的規則就是，如果還沒有準備好重寫所有背景代碼進而自己試試api，那麼最好避免開發api。要像思考任何新産品那樣仔細全面地思考開發api的決策。這樣，你才能高效投入到建構兩個新産品裡，因為不能不使用api。

當api是你自己産品的正式背景時，那麼很容易保持代碼dry——不重複自己。特性直接為api而開發，這使得可以立即向客戶釋出特性。這也使得在将主要産品釋出給api使用者之前測試這些新特性容易得多。當制造者同時也是産品的使用者時，那麼所有api上存在的問題都會得到極大的重視。bug會被立即修複，因為它們影響到所有人。

随着開發人員越來越頻繁地使用第三方api，我發現大家都能夠指出哪些是核心産品的核心部分，哪些是後來添加的東西。不需要專家就能建構出品質良好的産品，開發人員會主動解決使用産品直接會遇到的問題：這在後來開發的api裡就缺失這樣的關注。

本文轉自d1net（轉載）