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