如何提高設計 API 的能力? | 知乎問答精選

 

A-A+

如何提高設計 API 的能力?

2017年08月16日 知乎問答精選 暫無評論 閱讀 8 ℃ 次

【vczh的回答(49票)】:

平時設計的狗屎API自己要吃,吃多了你就知道什麼是香的了。然後你的能力就得到了提高。

@關中游 說的挺好。這就跟你寫一個GUI軟件,然後綠綠一用,發現你localization做的不好,顯示綠綠文是從左到右的,光標還能放到一個字的中間,第二天就會有人肉炸彈了哈哈哈哈

【關中游的回答(27票)】:

先補腦使用我的API的都是脾氣暴躁,腦子遲鈍,毫無概念的同類。

  1. 把實現過程中產生的中間抽像層和膠合層代碼盡量吞掉,讓他能看不到一絲痕跡。告訴他,這個世界簡單美好。

  2. 把可能出現的邊界狀態都考慮到,做好API內部的容錯,出錯了要耐心的告訴他腦袋哪根筋撘錯了,想對待小朋友一樣呵護使用我API的同類。

  3. 用最靠近正常人思維的方式表達抽像層。就算犧牲點效率和增加開發工作量,也是可以理解的。
  4. 多吃自己的留下的剩飯,吃出病來,在病床上痛苦了一陣,自然知道錯在哪。然後,多看看開源庫裡面的代碼,看看為啥人家做的飯就是比我好吃。
  5. 出國走走,多接觸幾門語言。
  6. 學會KISS。

【知乎用戶的回答(22票)】:

1、依賴倒置原則

依賴倒置的意思,是不要想像別人應該怎麼用你的API、以及用你的API做什麼;而是「倒」過來想,我的API對外提供了一個什麼樣的抽像、這個抽像是否夠好、夠簡潔,有沒有把不必要的細節暴露給用戶。

比如說,之前我所在的公司做了個類似電子商城的東西,其它項目組做出產品,就放在這個商城裡面銷售。

那個商城團隊就犯了干涉他人實現的大忌:他們非要瞭解其他項目組的邏輯,才知道如何才能把別人的產品上架銷售。不要這樣。

這種做法就導致兩個團隊耦合過重;且新產品和老產品邏輯無法兼容、甚至因為修改邏輯去迎合新產品,導致老產品銷售邏輯出現問題——又因為怕老產品出現問題,於是不得不逼新產品去適應老產品的流程,而不管兩者差別有多大。

這就導致,我們經常花1個月實現了一個新產品;為了把它上架卻經常需要3個月甚至超過半年——並且,商城團隊和其它項目團隊都必須加班、修改邏輯,甚至經常因為商城方提出的詭異邏輯/需求而出現摩擦(這夥人傻的……我都忍不住發過幾次火……

實在看不下去,我就給了一個方案,要求商城團隊修改。

這個方案基於依賴倒置原則,要求商城對外提供一個商品的抽像;商品的定義是有名字有價格、通過銷售轉移所有權的邏輯實體。

如此一來,任何項目想要上架,只要給自己起個名字、定個價格、用html或某種富文本格式或商城項目組喜歡的任何格式提供一段商品介紹、最後再提供一個「所有權成功轉移給xx用戶」的回調接口即可。雙方從此再不需要哪怕一個字的交流。

這個接口可以永遠不修改哪怕一個字節,足以支持任何商品種類的交易。

(事實上,我們團隊就是按這個要求寫程序的。寫完再和商城團隊扯皮。這可以避免他們動輒增加的豬邏輯/需求影響到我們的內部結構:隨便他們要什麼,我們都可以弄個空邏輯或者不同商品規格搪塞過去)

但商城團隊覺得一旦做成這樣,他們以後就沒事可幹了,所以拒絕修改……

好在,後來他們集體辭職了。

——如果你的接口不能穩定,那麼你一定違反了依賴倒置原則,或者是做了一個超爛的抽像。

——至於什麼叫好抽像,請參考KISS原則

2、完整且最小原則

完整,就是接口的功能要完整,該有的功能必須有;最小,是接口功能沒有冗余,不要接口A提供的功能,用一點外部邏輯再加上接口B或者接口B+接口C也能實現。

當然,這是一個比較理想化的指標。某些時候,為了易用性或者性能,是可以甚至必須做一些更簡單、方便、易用,但加起來卻不是最簡的接口的。

但,這個完整且最小的接口必須找出來。它是一切的基礎,也體現了開發者是否已經做出了一個清晰的抽像。

有了它,其它可以以後慢慢補;但如果沒有這個基礎,什麼易用、簡潔,都不過是扯淡。

我寧可用一個繁瑣、難用、難理解,但可保證不變的接口,也不想碰做點簡單的活計非常方便、易用,但根本沒法實現稍難的需求、並且不能保證穩定的接口。

事實上,兩者的差別就在於有沒有好的抽像;而一旦有了好的抽像,哪怕想做得繁瑣、難用、難理解,都不是容易的事。

總結:有了好的抽像,接口才可能穩定;然後找出完整且最小的接口,那麼只要抽像不變,這個接口就絕對穩定;最後,在這個基礎之上,做出易用、易理解的接口。

【yuewang的回答(2票)】:

去大公司(Facebook, Google, Microsoft, Apple 等)實習或工作。

設計是一個抽像的過程,是把業務代碼抽像成一個個模塊,研究這些模塊如何耦合如何可以方便拓展的問題。

如果你自己一個人寫代碼,你什麼都學不到。自己寫個幾千行的代碼的應用,怎麼直接怎麼來。

去小公司也沒用(小不指人數多少),小公司看市場要什麼就做什麼,大多保證可以湊活用,以佔領市場可以做大做強。項目代碼其實不會很好。

只有去大公司後,你才能真正學會怎麼設計:

- 大公司業務複雜,內部邏輯很多,一個普通的系統,它還要考慮速度,拓展能力,和之前的兼容性等等的問題。所以大公司代碼都極其抽像,除非發佈時間緊,否則不會硬著頭皮寫。

- 大公司一般都有錢能招到一流的架構師來抽像他們的核心業務。你看看那些代碼,能從中學到很多。

- 大公司對新人會由易到難給一些具體項目,要求做設計,然後別的同行(一般是組裡經驗多些的)會指導你、改進你的設計。

【nonocast的回答(2票)】:

吃自己的狗屎,最好的方法了。

【HanyuLiu的回答(0票)】:

最省勁的辦法當然是剖析相關的項目。

但幹這個前提是你有一定的相關經驗:1.你要知道這套API的所有需求是什麼;2.類似的API有哪些不舒服的地方;3.你要能明白,已有的API(比如類似的其他項目)為什麼這麼設計(你認同的和不認同的)。

//

有些答案提到「自己使用自己的API」,這個我認為已經是改進的步驟了,是下一個開發週期的問題。對你第一版的設計,其實並沒有什麼幫助。

【Levski的回答(0票)】:

這個問題挺有意思的,大家也都從API設計本身聊了一些自己的切身感受。所以我想從另外一個角度,跳出API設計這個問題,談談我對如何設計API的看法。

在我看來,「如何提高設計API的能力」,和「如何提高文章的能力」、「如何提高解數學題的能力」一樣,是一個看上去「難者不會,會者不難」的問題(當然實際上並非如此),也正是因為這樣,像LZ這樣的有上進心的同學,才會在市面上或者網絡上搜索各種學習方法,希望通過學習這些「學習方法」,提高自己對應的能力。

但是從我們自己這麼多年的學習經驗來看,那些學習方法有多少在事前是有效的?就我自己的經驗來看,很多「方法」如果沒有親自跌倒再爬起來的體會,是很難真正運用的起來的。這就像你讓一個初級程序員看Code Complete和GoF的《Design Patterns》一樣,也許你覺得你理解了,但是其實你還真沒理解。。。

所以LZ的這個疑問就可以轉化成「如何讓自己對API設計擁有這種」親身經歷「般的體驗?這時候,以上諸位的答案就可以用得上了,無非就是一句話「Shut up and code」

如果LZ感覺是因為你沒經驗導致不知道如何設計API,那最好的方式就是衝進槍林彈雨裡實戰,以後會不會把愛因斯坦的學識直接塞到別人的腦袋裡我不知道,但是現在,實戰是目前為止最好的讓初學者快速提高的最有效的辦法了。這時候無論是正確還是錯誤的方法論,對你而言都無法立竿見影的起到效果,所以是沒有什麼意義的。

當然,我知道「過來人」一定會反駁這種野路子的方法,但是我們無可否認,我們學習的目的不是為了學習本身,而是學以致用,所以沒有什麼比讓初學者快速看到他學習的成果更能讓他振奮的了

當然,如果如果已經有了一定的經驗,那應該就是另外的建議了,但是我猜LZ是第一種,所以這裡就不歪樓了,如果真有需求再新開問題吧 :-)

【junlee的回答(0票)】:

盡量拆散一點,最初做API是按著客戶端的需求來,客戶端要什麼就返回什麼。後來發現,客戶端需求一變,API就廢了,根本無法復用。比如登陸接口,客戶端要返回用戶性別等資料。

第二版,不向客戶端妥協,該有的功能都有,只不過按職能拆分,你需要自己去拼,別妄想一個接口返回多個接口的數據。比如登陸就是登陸,資料就是資料,別想一次返回。

後來,基本上只新增接口,很少改接口了。

【古易的回答(0票)】:

把自己吐槽口爆過的別人寫的api的內容拿出來,想想為什麼口爆別人,注意是為什麼而不是口爆的內容,根據自己項目的特點想著之前口爆的原因再做設計。最後依舊會被人口爆,這裡要注意的是想別人為什麼口爆,合理不合理,虛心接受,覺得無理取鬧就意思意思敷衍一下,重要是平常心想清楚,切不要別人說什麼是什麼,無論好壞。

至少我覺得,一個好東西,一定是在各種修改之後才會好的。這不是在說修改的重要性,而是要指出是否需要修改的判斷力。這個只有磨練或者靠天分了。

【PengDU的回答(0票)】:

有一本書:API Design for C++

【SanchaSu的回答(0票)】:

多讀好的代碼。

標籤:-編程 -醫療


相關資源:





給我留言