工作模式公司目前采用前后端分離的模式進行項目開發。本人處于后端組的Java開發職位。前后端的溝通橋梁前后端分離開發項目，前端組主要負責頁面的設計與交互，后端組主要負責數據的存儲與服務。前后端組工作協作靠接口文檔。目前本人公司的接口文檔由前端工程師主要填寫，后端人員進行后期的調整。發現的問題在前后端兩個小組協作開發項目的過程中，逐漸了發現了些許協作問題，以本人目前的眼界，認為最為突出的問題會發生在接口文檔上。結論緣由為什么本人會認為最大的問題出現在接口文檔，并在此請教改善之法呢？有以下幾點原因。前后端人員的思維差異接口文檔，表明了前端請求后端數據時的格式。本人公司采用json的數據格式進行數據交互，后端采用Java開發，自然是將model中的數據轉為json格式“跪送”給前端。但由于每個人的思維不用，對接口中的字段命名習慣等也大不相同。例如后端User類中有name和age兩個屬性，但前端人員寫接口文檔時偏偏是{“username”:“xxx”,“sex”:“xxx”}。為了應對這種情況，最開始開發項目時，后端再返回數據之前采用Map的方式將model中的數據進行重組和封裝，達到前端要求的接口內容。但Java代碼就泛濫出大量的put操作，甚是繁瑣。個人認為這種情況可以在開發前期兩組就要辦法做統一規范。前端人員填寫接口的“隨意性”為了避免Map方式所帶來的繁瑣操作和put代碼泛濫，隨后的項目開發中，引入了DTO類，并借助Dozer工具進行實體類DTO類之間的映射轉換。DTO類中的屬性名符合前端人員在接口文檔中所寫的字段名稱。例如為了傳輸User類的數據，對應的有UserDTO類，有username和sex屬性。同時DTO也可以應對傳輸實體類部分屬性的情況。OK，這種模式進行了一段時間后發現，由于前端人員寫接口太過隨意，導致后端會產生大量碎片化的DTO類。舉個詳細的例子：publicclassCourse{//課程實體類privateLongid;privateStringnumber;privateStringname;privateTeacherteacher;//課程教師}前端通過接口請求課程相關的數據時，可能是{"number":"xxx","name":"xxxxx"}，可能是{"id":xxx,"name":"xxxx"}，亦或是{"id":xx,"name":"xxx","teacherName":"xxx"}。這種“隨意性”導致后端要么創建應對各式各樣情況的DTO類，要么就是在實體類和DTO類中追加冗余的、沒有意義的屬性。例如又可能為了顯示，需要在Course類添加一個studentScore的屬性。當然“隨意性”我用了引號，表示這只是我個人的觀點，并不能說明前端人員有錯，人家在寫文檔時自然更偏向于自己認為舒服的結構，這很正常，本人表示充分理解。3.過于過程化的接口結構第三點是我近期所察覺到的最可怕的一點。諸如上述問題的存在，當遇到復雜的項目時，文檔結構就會失控。假如前端人員對后端的技術并不清楚的話，以及他們更偏向于過程化的編碼思維，直接導致接口結構呈現過程化的趨勢，可悲的是由于交互功能的復雜度，后端為了實現前端期望的接口結構，在編碼時已然潛移默化地在進行面向過程的開發，而不是面向對象，個人認為這是災難的征兆。說到這兒，我依舊不認為前端在寫接口有錯或是有問題，這是人家的正常思維習慣。以上是本人在自己工作經歷中所感悟的痛楚，在此請教各路有經驗人士的改善觀點。