背景

在這個SOA都已經成為過時概念的年代，為什麼還要寫一篇文章來講述介面開發呢？

這個問題很難一兩句話解釋清楚，打個簡單的比方，這個問題就好比在問：現今智慧手機、即時通訊工具都已經普及了，為什麼還要寫一篇文章來講述如何溝通呢？

是的，SOA、REST以及各種五花八門的RPC技術，都只是進行系統間整合的技術實現，這方面技術發展已經足夠繁榮了，但是作為問題的本質——介面本身，如何去設計 如何描述 如何治理卻較少被關注。 本文正是針對這個主題。

現狀

先來看一下目前在軟體開發現實世界中，典型的介面開發過程是什麼樣的：

• 首先 一個介面的需求被提出：某天，在一個大型組織內的某個IT專案A，一個開發人員甲在分析業務部門的剛剛發來的需求S時發現，需要從專案B處獲取幾類資料；
• 然後發起專案組間溝通協調：於是甲以正式或非正式方式 召集兩個專案組相關人員進行溝通討論，確認專案B能否提供資料、如何提供、何時開始提供；此時實際上就是在確定介面的大致規格（主要欄位資訊）、技術實現（同步or非同步 協議。。。）和開發進度；
• 會後，工作一向認真負責的甲 按例發出會議紀要，將雙方商定的技術細節發出來確認，並作為下一步開發工作的基礎；
• 由於業務部門要求儘快上線該需求，小甲把這個介面安排到了兩週後的最近一次釋出，於是發完郵件就離開開始起草介面規格文件，大概像下面這樣的文件：
• 兩天後 介面文件基本定稿，發給專案組B，雙方的開發人員立刻開始了開發工作，這個所謂的開發工作主要包括：
  • 把介面文件中描述的那些資料結構和欄位翻譯成JavaBean、雙方開發人員各自翻譯自己那部分介面模型；
  • 序列化與反序列化
  • 分別實現客戶端、服務端業務邏輯——服務端返回特定資料，客戶端對返回的結果進行處理；當然跨系統獲取資料，只是常見介面之一，另外還有遠端過程呼叫（事務性操作），不過從技術上沒有本質區別；
• 聯調測試
• 上線釋出

問題

但是現實世界中 事情沒有這麼簡單，由於普遍存在的熵增原理，很多時候看似簡單的事情在達到一定量 在較長時間範圍內就會不知不覺的變得複雜最後失控。

就像專案程式碼，用的都是面向物件高階語言，各種號稱靈活可擴充套件的技術架構和框架，但是幾乎所有專案都很不可避免的變成一團亂麻，統計顯示，軟體專案的失敗率依然很高，沒有隨著這幾十年的技術進步而有任何起色，軟體危機其實一直沒有結束。這裡不展開論述了。

具體到介面，為什麼在數量增加 時間推移之後 就會很快變亂失控呢？是什麼引起了熵快速增加？

根據我的觀察和分析，問題出在介面定義上面——普遍採用的文件定義介面的做法 為日後的危機埋下隱患。