前後端合作開發的時候經常需要用到介面文件，那麼介面文件在產品中究竟有什麼作用？該如何去規範呢？
假如你的專案中有若干前端和若干後端。你現在需要開發乙個登陸介面，通常情況下這個功能乙個前端和乙個後端開發就足夠了。有些公司的後端很強勢，因此可能出現後端寫好介面之後告訴前端去開發頁面。也可能前端很強勢，因此前端寫好頁面之後讓後端去寫介面。 這兩種情況都不是我們希望見到的。這是因為如果我們自由開發乙個介面，後端開發人員通常會選擇最符合後端直覺的方式去寫介面。反過來，對於前端開發人員來說，他們一定會選擇最容易展示的方式去寫頁面。這兩種直覺之間是會有差異的，因此這樣的一方主導開發的情況很容易出現各種各樣的意外情況。 所以為了避免這樣的情況，我們需要介面文件來約束前後端的協同開發。
雖然現在前後端分離居多，但是如果我自己乙個前後端都可以做，肯定會了解前後端各自的特點，就不會因為開發思路的差異而導致出現意外。那麼對於我來說，是不是介面文件就沒必要存在了呢？ 答案顯然是否定的。介面文件的另乙個重要作用就是規範。 專案需求變動是很常見的情況，舉個例子，我們現在有乙個學生表。頁面上需要用乙個**展示所有的學生，可以分頁操作。 假設現在的介面文件是這樣的：
然後需求變動了，我們需要把學生表展示為教師表。
這兩個介面從後台邏輯來說應該是完全一致的。唯一的差別是我們需要查不同的表。從前台邏輯來說，這兩個除了介面不一樣，其他的分頁字段應該是一致的。理想情況下如果乙個前端開發接手這個頁面之後，完全可以不看文件直接改api位址，然後修改頁面的填充資料就可以了。 現實是，很多介面的規範做的不好。這就導致了，邏輯相同的兩個介面，他們的查詢引數可能是不一樣的。這樣就會出現下面的情況：
返回內容的更改是沒問題的，但是因為兩個介面沒有規範，這就導致其他開發人員接手的時候不僅需要改資料的格式，也需要更改引數名。這在無形中就降低了開發效率。 另一方面，文件健全肯定是好的。但是毫無規律，隨意編寫的文件卻會降低開發效率。因此健全的文件必須要配合良好的文件規範，這樣才可以讓開發人員可以預估api返回的資料格式和請求引數。
基本上每個遊戲都有乙個版本號。這個版本號是**的版本，表示這個版本的**有相應的功能。同樣的道理，文件也需要通過版本進行管理。每個版本的api都要有相應版本的介面文件。這樣當專案需要回滾的時候我們可以馬上知道上個版本的需求。
訊息中介軟體在專案中的作用
乙個使用者登入了系統，將傳送通知給積分系統集群和日誌系統集群，要求積分系統集群和日誌系統集群都能接收到完整的登入實現通知，類似於主題模式，同時在其中任乙個系統群中不能讓乙個訊息被集群中的多個系統重複處理，這類似於佇列模式。子業務系統都有集群的可能性 同乙個訊息會廣播給關注該類訊息的所有子業務系統 同...
專案中文件的認識
專案設計階段 總體設計說明文件 這是頂層設計，整個系統的構想，系統下各子系統之間的介面 關聯的框架圖。2.具體技術細節實施方案說明 這是執行層的設計文件 子系統 子模組 子功能這樣一級一級的往下分解，最後分解到具體的每個功能點 關鍵邏輯點。著重闡述實現該功能點的技術選型 優劣對比，最終採用的技術方案...
業務分析師在敏捷專案中的作用
我的觀點是 沒有業務分析人員，就會發生真的斷層。舉例來說 在agile 2008大會上，alan cooper做了乙個很棒的演講 他熱情洋溢地提到 敏捷專案中需要包含互動設計的工作，要有人能夠理解人的行為 而且可以確保相關的產品能夠在現實世界中有效工作。我的觀點是 最理想 最有效的做法，是由業務分析...