目前問(wèn)題
- 接口文檔更新不及時(shí)，增加聯(lián)調(diào)時(shí)間，降低交付速度
- 接口文檔更改后，前端接口層，后端接口層及測(cè)試用例均需要各自修改，增加開(kāi)發(fā)成本
解決思路
在前后端交互中，涉及到四個(gè)東西
- 接口文檔H
- 前端接口層CI
- 后端接口層BI
- 測(cè)試用例TC
假設(shè)后續(xù)接口做了一個(gè)修改操作m，比如說(shuō)m是增加一個(gè)參數(shù)，m對(duì)四者而言都是同一個(gè)變動(dòng)因素，則
H' = FH(H,DSL(m))
CI' = FC(CI,DSL(m))
BI' = FB(BI,DSL(m))
TC' = FT(TC,DSL(m))
其中DSL是使用語(yǔ)言結(jié)構(gòu)化描述操作m，這部分操作需要去按DSL規(guī)范手工更改。FX函數(shù)是對(duì)變化m產(chǎn)生新的描述處理過(guò)程。
正常而言，需要做到自動(dòng)化，需要做到
- 找到一種DSL方式描述m
- 開(kāi)發(fā)4個(gè)FX函數(shù)
為了降低開(kāi)發(fā)成本，我們可以選擇使用DSL描述H，通過(guò)按規(guī)范把變化m加入到H中變成H'，然后其他三個(gè)函數(shù)變成
CI' = FC(H')
BI' = FB(H')
TC' = FT(H')
這是為了簡(jiǎn)化編程模式，采用修改全覆蓋策略，換句話說(shuō)三者的變化只跟H'相關(guān)，與自身前后狀態(tài)無(wú)關(guān)。
為了達(dá)到這一點(diǎn)，需要的工作是
- 選擇DSL描述H
- 開(kāi)發(fā)三個(gè)不同的FX函數(shù)
解決方案
解決方案基于兩點(diǎn)出發(fā)
- 最大限度使用現(xiàn)有工具鏈
- 最小侵入性及最小開(kāi)發(fā)工作量
對(duì)于接口描述的DSL，我們可以選擇有很多語(yǔ)言都支持的json，xml和yaml等，免去開(kāi)發(fā)解析的成本。
對(duì)于后面三個(gè)函數(shù)的開(kāi)發(fā)，根據(jù)我們的業(yè)務(wù)類(lèi)型，需要做的工作
- Android端Java接口層代碼和Model層自動(dòng)生成
- iOS端OC接口層和Model層自動(dòng)生成
- J2EE端Form層自動(dòng)生成
- 測(cè)試端測(cè)試頁(yè)面及測(cè)試用例自動(dòng)生成
這塊業(yè)界已經(jīng)有較為完善的解決方案，比如swagger
- 使用yaml描述接口及交互數(shù)據(jù)結(jié)構(gòu)定義，DEMO
- 可以生成client端（Android和iOS）和server端（Spring MVC）的代碼
- 測(cè)試接口頁(yè)面自動(dòng)生成，DEMO
基本上已經(jīng)滿足我們這邊的需求（測(cè)試用例自動(dòng)生成這塊跟測(cè)試組同學(xué)再進(jìn)行詳細(xì)溝通），我們需要根據(jù)自身的框架修改部分自動(dòng)代碼生成的代碼
收益評(píng)估
如果解決方案落地，主要的收益有
- 規(guī)范化接口文檔定義，增加項(xiàng)目可維護(hù)性
- 統(tǒng)一多端接口層定義，并且通過(guò)自動(dòng)生成方式減少人工投入和聯(lián)調(diào)成本
在此基礎(chǔ)上，把方案與我們自身的持續(xù)集成平臺(tái)Jenkins相結(jié)合，還可以在修改接口定義的時(shí)候自動(dòng)修改響應(yīng)各端代碼接口層，這樣的好處有
- 避免因接口更改沒(méi)通知到位而產(chǎn)生的溝通及聯(lián)調(diào)成本
- 由于接口定義改變導(dǎo)致各端接口層改變，強(qiáng)制各端工程師及時(shí)響應(yīng)并做響應(yīng)更改
- 提供交付速度和代碼質(zhì)量
實(shí)現(xiàn)計(jì)劃
由于這個(gè)方案涉及到多端人員，涉及前端，后端，測(cè)試三個(gè)組織，從落地角度來(lái)說(shuō)，可以先在部門(mén)內(nèi)部先落地，前期先把基礎(chǔ)服務(wù)后端接口定義引入，然后逐步把后端接口層自動(dòng)化及測(cè)試用例自動(dòng)化做起來(lái)，最后再推動(dòng)Android和iOS端接口層自動(dòng)化。
