簡單地構(gòu)建一個API是不夠的。如果在發(fā)布API之前不能“先自己試試”,那么結(jié)局就是失敗。Zachary Flower詳細解釋了個中原因。創(chuàng)業(yè)公司的開發(fā)生命周期必然充滿妥協(xié)。有太多東西需要完成,但是沒有足夠的資源保證所有東西都“正確”完成,因此開發(fā)人員在恰當(dāng)?shù)臅r候必須妥協(xié)。不幸的是,為產(chǎn)品構(gòu)建API與其說是技術(shù)決策,不如定義成業(yè)務(wù)決策更為貼切,這也正是需要妥協(xié)的地方。
為已有產(chǎn)品構(gòu)建API的挑戰(zhàn)是,業(yè)務(wù)需求總是最重要的。為了跟上業(yè)務(wù)需求的腳步,我們通常被強迫在產(chǎn)品質(zhì)量上作出讓步,這在創(chuàng)業(yè)公司應(yīng)用開發(fā)過程中很常見,也絕對是API開發(fā)的最差方式。
開發(fā)API時最重要的一件事是就是使用它。“Dogfooding”是創(chuàng)業(yè)論壇里的流行詞匯,用來描述企業(yè)規(guī)律地使用自己的產(chǎn)品,從而更好服務(wù)客戶的行為。在創(chuàng)建API時,能夠“先自己試試”極其重要,因為其向開發(fā)人員提供了一種方式來集成業(yè)務(wù)的核心功能到自己的產(chǎn)品里。如果這樣,或者作為主要產(chǎn)品的一部分,API無法正常工作,那么開發(fā)人員,及其用戶,注定無法獲得良好的用戶體驗。這會讓所有人都感覺很糟糕。
挑戰(zhàn)代碼基如果在構(gòu)建API時不先自己試試,那么可能最終需要管理兩個單獨的,大部分功能一樣的代碼基。第一個代碼基,主要產(chǎn)品,是大部分開發(fā)活動發(fā)生的地方。因此,它比第二個代碼基,API,更加清晰并且功能更為豐富。
被稱為“第二個”代碼基的API,會很快成為無主代碼。它的更新很繁瑣,和實際開發(fā)相比更像數(shù)據(jù)處理的工作,因為大部分工作是從“主要”代碼基里拷貝方法出來。因為其特性和bug修復(fù)晚于主要產(chǎn)品,這會使得用戶——至少堅持在使用的消費者——感到上當(dāng)受騙,甚至可能感到被開發(fā)人員背叛了。
API開發(fā)會最終延期,甚至可能完全終止,從而保證團隊將更多的資源關(guān)注于主要產(chǎn)品上。
正確還是完全不正確當(dāng)構(gòu)建API時,一個很好的規(guī)則就是,如果還沒有準備好重寫所有后臺代碼從而自己試試API,那么最好避免開發(fā)API。要像思考任何新產(chǎn)品那樣仔細全面地思考開發(fā)API的決策。這樣,你才能高效投入到構(gòu)建兩個新產(chǎn)品里,因為不能不使用API。
當(dāng)API是你自己產(chǎn)品的正式后臺時,那么很容易保持代碼DRY——不重復(fù)自己。特性直接為API而開發(fā),這使得可以立即向客戶發(fā)布特性。這也使得在將主要產(chǎn)品發(fā)布給API用戶之前測試這些新特性容易得多。當(dāng)制造者同時也是產(chǎn)品的用戶時,那么所有API上存在的問題都會得到極大的重視。Bug會被立即修復(fù),因為它們影響到所有人。
隨著開發(fā)人員越來越頻繁地使用第三方API,我發(fā)現(xiàn)大家都能夠指出哪些是核心產(chǎn)品的核心部分,哪些是后來添加的東西。不需要專家就能構(gòu)建出質(zhì)量良好的產(chǎn)品,開發(fā)人員會主動解決使用產(chǎn)品直接會遇到的問題:這在后來開發(fā)的API里就缺失這樣的關(guān)注。