但願給你3-5分鐘的碎片化學習,多是坐地鐵、等公交,聚沙成塔,水滴石穿,謝謝關注。html
先後端分離的開發模式,假如使用的是基於RESTful API的七層通信協議,在聯調的時候,如何避免配合過程當中出現問題?這裏分享一些不成熟的淺見。前端
咱們在先後端配合的過程當中,使用了大多數人使用的Swagger做爲服務描述文檔,這樣的好處很明顯,就是後臺編寫註釋,接口調用界面自動生成字段描述。以下圖:後端
隨着先後端磨合,默契程度逐步增長,基本上這種描述文檔足夠聯調了。事物老是多變的,隨着新人的加入和接口的增長,業務的複雜化,過了大半年,回頭望月,接口已經開始出現壞味道。api
新人不知道如何維護,連老人也要梳理回憶半天,接口膨脹致使分類不清晰,很難想象若是這個時候,若是大家須要把部分前端功能進行外包會怎樣?前端單看Swagger會不會一臉懵逼?微信
因而內部開個了專題會,參照市面上大多數的api描述文檔,你們贊成寫到wiki,雖然這種作法除了增長後端人員的工做量,對提高效率不是那麼明顯,可是整個接口的描述相對就規範一些。restful
過了一段時間,有一個前端新人進來,帶來了小小的煩惱,因爲後端接口變動,文檔沒有及時更新,前端在聯調時候常常一臉懵逼,若是能及時發現還好,不然將錯就錯,測試沒注意,發佈後常常犯一些寫錯別字的低級錯誤。框架
更加麻煩的是,項目工期趕,決定對前端部分模塊進行外包。因而準備好了UI圖和接口描述文檔,以爲應該能夠安心了。承包方拿到UI和文檔的時候,除了簡單的增刪改查接口大概能猜的懂,其餘的接口和UI上如何一一匹配?好吧,這該死的接口文檔。前後端分離
因而後臺兄弟加班加點在UI上給每一個功能一一標註對應的接口名稱,以下所示,雖然緩解了前端的困惑,可是先後端分離致使的一些效率損失,始終讓人耿耿於懷。也許就像DBA常常說的,任何事物都是有代價,不知道大夥有更好的解決方案賜教?學習
好比樹、表格、下拉、radio、複選框、時間……越早分類對後面的管理應該會更加有利,由於不一樣的新人進來,可能一樣的樹會從新造一種格式。測試
不能太多致使失控,也不能重複兩份接口(不一樣的開發者徹底有這種可能),不一樣的前端組件好比easyUI和elementUI對格式要求是不同的,若是先後臺用的不是同一套UI框架,接口有可能會出現重複。
每一個公司規範不盡相同,能夠參考大廠的規範,好比高德,微信或者百度地圖。對新入職的新要培訓在前,開發中出現新的問題,最好要有專題會進行討論協商一致,最後口頭的東西務必要文檔化,不然都不能算是真正的規範。
隨着團隊人數、業務擴大,若是沒有很好的規範,碰到溝通衝突的狀況,規範就顯得特別重要。咱們團隊本來兩個先後端配合融洽,相安無事,後面來了兩個新的先後端,因爲言語衝突,一件簡單的小事會由於個性不合而被無限放大。儘快統一風格,規範文檔化也許能夠避免不少相似的問題。
這裏給哪些想要作先後端分離的人一個不錯的RESTful API的規範,是阮一峯大神的博客,很是值得收藏,推薦下:RESTful API 最佳實踐