介面是目前：前後端互動(rest)，系統互動(rpc)最普遍的一種方式。乙個好的介面，應該清晰易懂，職責明確，易於維護。反之，則會造成很多困擾。特別是open api，誰做誰知道。基於這樣的前提以及自己之前踩過的坑，就成了這篇文章的由來。
文件與程式設計師之間有著一種非常奇妙的關係。一句話概括就是：」寫之，痛之。用之，悔之」。怎麼解釋呢？就是：寫的時候覺得很痛苦，不願意寫！用的時候呢，又後悔當初沒有留下文件！可見文件是多麼重要。以rest介面為例，文件需要詳細的記錄請求引數，返回引數，每個欄位的意思，是否必填，請求方法等。隨著**的更新，文件也應該及時更新。在很多開發者眼裡(包括我自己)，覺得寫文件是一件浪費時間的事情，寫**才是正經事。隨著工作經驗的積累，愈發覺得文件的重要性，不但沒浪費時間，反而還在節省時間。
這個原則其實是有點像設計模式中的迪公尺特法則(也稱為：最小知識原則)，不過我認為這其中包含了兩層意思：
其一：在介面設計中，請求引數在保證功能的前提下：盡可能的減少引數，更不允許新增無用的引數。以rest介面為例：一旦新增了無用的引數，在後續迭代過程中，就會遇到：棄之可惜，留之無用的尷尬局面。對於 client 端也會造成困擾，還會浪費頻寬。
其二：介面粒度應該盡量小且保持單一職責，不要寫大而全的介面。單一職責的好處不必多說，是乙個老生常談的問題。
在介面設計中，新老介面的相容是必須要考慮的，堪稱事故多發地。
常見事故如下所示：
v1 版本 api 上線發布後。隨著需求變化，需要在v2 介面版本中新增幾個字段。上線後，發現使用v1 版本的客戶端業務中斷。(v1版本沒有相容v2版本(新字段)導致)。
v1 版本 api 上線發布後。隨著需求變化，需要刪除某個介面。系統上線後，造成低版本客戶端業務中斷 (沒有相容老的client version 導致)。
對於這種情況，api介面的更新：一般會採用 新老版本並行使用 進行過渡，並在大版本中進行逐步更新，直至沒有client version進行使用時，api介面才能進行下線。
同樣的道理，放在內部的 rpc 介面也適用。前一段時間還犯了乙個這樣的錯，事情是這樣的：在更新乙個必須強制更新rpc介面時，採用了同步發布法。當時以為全部理清楚所有呼叫端，上線後，依然造成了生產事故，因為還有乙個呼叫端沒有在計畫內。這樣做的弊端包括但不限於以下幾點：
涉及應用多，(如果該介面為底層服務，那呼叫的上層應用都需要同步修改，一旦缺少乙個，則會發布失敗)。
發布時間長
事實上：我們應該盡量避免這種」同步發布法」，這也是阿里研究員谷樸老師在 《api 設計最佳實踐的思考》中特別提到的一點。
這個確實是乙個容易忽略的細節。我自己也有過這樣的經歷，特別是一些策略性的**及產品**中，非常容易出現這樣的現象。例如：某段**一開始是有的，後面因為優化也好，因為調整也好，要去掉。但 「 自認為 「 後面還是會使用，則將其注釋之。時而久之，這段注釋的灰**就此扎根，誰也不敢修改。**中的壞味道就此慢慢的發酵，直至變臭。因此：無論從擴充套件方面，還是可維護方面考慮，都建議及時清除不必要的**。
介面設計的五點建議！
介面是目前 前後端互動 rest 系統互動 rpc 最普遍的一種方式。乙個好的介面，應該清晰易懂，職責明確，易於維護。反之，則會造成很多困擾。特別是open api，誰做誰知道。基於這樣的前提以及自己之前踩過的坑，就成了這篇文章的由來。文件與程式設計師之間有著一種非常奇妙的關係。一句話概括就是 寫之...
UI介面設計 介面設計流程
人類社會逐步向非物質社會邁進，網際網路資訊產業已經走入我們的生活。在這樣乙個非物質社會中，與軟體這些非物質產品再也不象過去那樣緊緊靠技術就能處於不敗之地。工業設計開始關注非物質產品。但是在國內依然普遍存在這樣乙個稱呼 美工 工 的意思就是沒有思想緊緊靠體力工作的人。這是乙個很愚昧的做法，愚昧在於稱呼...
介面設計定理
介面設計定理 模組分解原理探索 模組分解原理與三權分立 介面關係穩定原理探索 前面幾篇文章中講過模組分解原理和介面關係穩定原理，這篇文章中將使用模組分解原理和介面關係穩定原理來推導乙個重要的定理 介面設計定理。在講解介面設計定理前，先看一下robert c.martin著的 敏捷軟體開發 一書中提到...