簡單地構(gòu)建一個(gè)API是不夠的。如果在發(fā)布API之前不能“先自己試試”，那么結(jié)局就是失敗。Zachary Flower詳細(xì)解釋了個(gè)中原因。創(chuàng)業(yè)公司的開發(fā)生命周期必然充滿妥協(xié)。有太多東西需要完成，但是沒有足夠的資源保證所有東西都“正確”完成，因此開發(fā)人員在恰當(dāng)?shù)臅r(shí)候必須妥協(xié)。不幸的是，為產(chǎn)品構(gòu)建API與其說是技術(shù)決策，不如定義成業(yè)務(wù)決策更為貼切，這也正是需要妥協(xié)的地方。

為已有產(chǎn)品構(gòu)建API的挑戰(zhàn)是，業(yè)務(wù)需求總是最重要的。為了跟上業(yè)務(wù)需求的腳步，我們通常被強(qiáng)迫在產(chǎn)品質(zhì)量上作出讓步，這在創(chuàng)業(yè)公司應(yīng)用開發(fā)過程中很常見，也絕對(duì)是API開發(fā)的最差方式。

開發(fā)API時(shí)最重要的一件事是就是使用它。“Dogfooding”是創(chuàng)業(yè)論壇里的流行詞匯，用來描述企業(yè)規(guī)律地使用自己的產(chǎn)品，從而更好服務(wù)客戶的行為。在創(chuàng)建API時(shí)，能夠“先自己試試”極其重要，因?yàn)槠湎蜷_發(fā)人員提供了一種方式來集成業(yè)務(wù)的核心功能到自己的產(chǎn)品里。如果這樣，或者作為主要產(chǎn)品的一部分，API無法正常工作，那么開發(fā)人員，及其用戶，注定無法獲得良好的用戶體驗(yàn)。這會(huì)讓所有人都感覺很糟糕。

如果在構(gòu)建API時(shí)不先自己試試，那么可能最終需要管理兩個(gè)單獨(dú)的，大部分功能一樣的代碼基。第一個(gè)代碼基，主要產(chǎn)品，是大部分開發(fā)活動(dòng)發(fā)生的地方。因此，它比第二個(gè)代碼基，API，更加清晰并且功能更為豐富。

被稱為“第二個(gè)”代碼基的API，會(huì)很快成為無主代碼。它的更新很繁瑣，和實(shí)際開發(fā)相比更像數(shù)據(jù)處理的工作，因?yàn)榇蟛糠止ぷ魇菑?ldquo;主要”代碼基里拷貝方法出來。因?yàn)槠涮匦院蚥ug修復(fù)晚于主要產(chǎn)品，這會(huì)使得用戶——至少堅(jiān)持在使用的消費(fèi)者——感到上當(dāng)受騙，甚至可能感到被開發(fā)人員背叛了。

API開發(fā)會(huì)最終延期，甚至可能完全終止，從而保證團(tuán)隊(duì)將更多的資源關(guān)注于主要產(chǎn)品上。

當(dāng)構(gòu)建API時(shí)，一個(gè)很好的規(guī)則就是，如果還沒有準(zhǔn)備好重寫所有后臺(tái)代碼從而自己試試API，那么最好避免開發(fā)API。要像思考任何新產(chǎn)品那樣仔細(xì)全面地思考開發(fā)API的決策。這樣，你才能高效投入到構(gòu)建兩個(gè)新產(chǎn)品里，因?yàn)椴荒懿皇褂肁PI。

當(dāng)API是你自己產(chǎn)品的正式后臺(tái)時(shí)，那么很容易保持代碼DRY——不重復(fù)自己。特性直接為API而開發(fā)，這使得可以立即向客戶發(fā)布特性。這也使得在將主要產(chǎn)品發(fā)布給API用戶之前測試這些新特性容易得多。當(dāng)制造者同時(shí)也是產(chǎn)品的用戶時(shí)，那么所有API上存在的問題都會(huì)得到極大的重視。Bug會(huì)被立即修復(fù)，因?yàn)樗鼈冇绊懙剿腥恕?/p>

隨著開發(fā)人員越來越頻繁地使用第三方API，我發(fā)現(xiàn)大家都能夠指出哪些是核心產(chǎn)品的核心部分，哪些是后來添加的東西。不需要專家就能構(gòu)建出質(zhì)量良好的產(chǎn)品，開發(fā)人員會(huì)主動(dòng)解決使用產(chǎn)品直接會(huì)遇到的問題：這在后來開發(fā)的API里就缺失這樣的關(guān)注。