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