優秀API設計的十大原則 兄弟連IT教育

2021-07-05 12:46:14 字數 1266 閱讀 2471

優秀api設計的十大原則—兄弟連it教育

每個軟體開發人員都使用api。「優秀」的api設計就像魔法。不過,我不知道有多少人可以解釋為什麼有的api很複雜、很難學,而有的則乾淨、簡單、使用起來堪稱是一種快樂。關於這個問題,我將在文中回答,並提供優秀api設計的十條法則。

1.只做你今天需要的

這是最頂級的規則。只解決今天必須解決的問題,最小化需要完成的答案。解決明天的問題的**力是巨大的。但是一定要頂住**!不要提前發布**,重點是注重縮小發布週期。如果需要花幾個小時的時間來回答新問題,那麼就不用再猜測明天會出現什麼問題了。

2.api模組化

將大型問題轉化為規模較小的、可單獨解決的問題。模組化api更容易學習,並且可以隨時間而改變。你可以用新模組替代舊模組。可以乙個乙個地教導模組。也可以將api的實驗部分從穩定或傳統的部分中單獨分出來。

3.使用結構化語法

使用結構化的api語法:用thing.action或thing.property代替do_action_with_thing。語法將自然而然地適應模組化的方法,其中每個模組是乙個類。

4.使用自然語義

不要發明新概念。只使用開發人員眾所周知的概念,作為類系統的基礎。如果你發現自己需要解釋概念,那說明你出錯了:要麼你在解決以後的問題,要麼你正在錯誤地構建api。

5.api的自我約定

每個類都要嚴格使用相同的樣式和約定。一致性是指當乙個人學會這乙個類時,他就能夠融會貫通地掌握全部的類。文件化約定,讓它們成為貢獻者必須的標準。

6.api的可擴充套件性

易擴充套件性有許多好處,並不僅僅在於受到貢獻者的歡迎。它還可以讓你延緩實現功能,因為「如果需要的話,後面再新增也很方便」。不需要的功能就不新增,這也是一種雙贏。

7.完全測試

每個類和方法必須經過惡意**的完全測試。要像寫**一樣寫測試,然後像api提供給外界約定文件一樣使用測試。每當**改變的時候就執行這些測試。不要擔心**覆蓋率。重要的是外部約定。也可以考慮使用約定生命週期。

8.分層式成長

保持api突出重點,然後在頂部將新的api分層,以便於它們能隨著時間的推移成長。可擴充套件性並不意味著無限期的成長。明確api的範圍,並在範圍內執行。

9.保持簡單易用

最終的測試要看api的簡單易用程度。你寫的例子,能不能讓你的**看起來更簡單?你是不是強迫使用者說明他們不在乎的選項?有沒有毫無價值的額外步驟?要注重約減少api的可視面積。

10.保持可移植性

不要讓系統概念洩漏到api。整潔有目的地抽象:這個api可以執行在任何作業系統上。api必須能夠隱藏實現,但要注意第4條規則,以及要使用自然抽象。

測試十大原則

1.所有測試的標準都是建立在使用者需求之上。正如我們所知,測試的目標就是驗證產品的一致性和確認產品是否滿足客戶的需求,所以測試人員要始終站在使用者的角度去看問題 去判斷軟體缺陷的影響,系統中最嚴重的錯誤是那些導致程式無法滿足使用者需求的缺陷。2.軟體測試必須基於 質量第一 的思想去開展各項工作,當時...

Hive優化十大原則

一 表鏈結優化 1.將大表放最後 hive假定查詢中最後乙個表是大表,他會將其他表先快取起來,然後掃瞄最後那個表。因此通常需要將小表放在前面,或者標記那張表是大表 streamtable table name 2.使用相同的鏈結鍵 當對3個或者更多個表進行join連線時,如果每個on子句都是用相同的...

hive優化十大原則

hive之於資料民工,就如同鋤頭之於農民伯伯。hive用的好,才能從地里 資料庫 裡挖出更多的資料來。用過hive的朋友,我想或多或少都有類似的經歷 一天下來,沒跑幾次hive,就到下班時間了。hive在極大資料或者資料不平衡等情況下,表現往往一般,因此也出現了presto spark sql等替代...