目前應該大部分公司都采用前后端分離的方案吧,然后在開發聯調和自測的過程中難免會遇到各種情況需要后端給你各種情況的數據來觸發各種場景。這種時候就需要 一種可以在不影響開發并且可以讓你可以得到各種所需要的數據的解決方案了~
那么目前想到的方案
方案1 直接修改字段屬性
強行進入所場景這種方案在如果只是改一個字段的true或者false那么還好 但是如果在需要多個數據的修改才能觸發的場景,那么修改成本大概就有點高了吧=。= 而且有可能因為忘記了而導致線上出問題
//比如 有一個三級的狀態 由于需要修改stage = 2 round = 3 team = 3的情況就要在代碼中這么到處修改
data(){
return {
//stage: 1,
stage: 2
...
//round: 2
round: 3,
//team: 1,
team: 3
}
}
這方法優點是夠簡單暴力，但是弊端也很明顯 容易遺漏，在一般非請求的情況可能會用到，不過就算是非請求通過組織好代碼流程也能用更好的方法解決，這里就不討論了
方案2 在接口處寫入一段假數據
這種方案好處就是只要在success處寫一段假數據 就能進入需要的場景并且也不需要后端給到你需要場景的數據，只要能接口通了就可以，但是還是有一個問題 就是首先得后端先有接口=。= 按我的經驗... 后端大佬一般都沒這么快能給你接口 有文檔已經很不錯了~
axios.get('xxx').then(res => {
// this.info = res.data.info
this.info = {
nickname: '魯路修·Vi·不列顛尼亞',
age: 18,
sex: 'gay'
}
})
還是上面的問題，因為模擬數據寫了在業務代碼里面了，就存在可能人為因素忘記刪掉不該有的代碼的問題，而且這辦法也太辣雞了點，不優雅
好了，上面兩條比較簡單的做法可以總結出來 數據不能在業務代碼中模擬 不然很容易出現問題
那么如何在不影響業務代碼的情況下 通過自己模擬數據達到前端自己實現后端數據呢~
方案3 封裝請求接口 在請求處實現mock邏輯
在實現邏輯的時候，難免會有各種ajax請求或者什么請求之類的 那么如果在代碼中各種請求滿天飛 那不是感覺很辣雞嘛... 那么就把所以請求的url集中起來管理，把請求頭通過一個統一的變量管理起來。通過封裝一個API的類來管理你的所有API，只要調用API的方法就可以實現請求了。然后既然API的類也有了，通過改造API類里面的對應url里面的方法，在對應方法里面寫mock數據，就能做到不影響業務邏輯的情況下實現mock數據了~
比如
//App.vue
APIS.getUserInfo()
.done(res => {
//業務邏輯
})
.fail(err => {
//錯誤處理
})
//apilist.js
getUserInfo(data, params){
return this.mock({
code: 0,
data: {
xxx: 1,
bbb: 2
}
})
}
講道理這個方法其實就是模仿我們大佬實現的api的封裝方案噠~ 最近看了一下感覺好像有點jq的ajax寫法的感覺哦 也不知道他是不是也是從那里拿靈感的 不知道他看到了會不會找我談心呢 具體ajax怎么封裝就不寫出來了~
方案4 本地實現服務端接口返回對應數據
雖然方案3已經可以很大程度避免由于模擬數據影響業務邏輯了，但是如果有方法可以完全不影響項目代碼是不是更好呢？
//server.js
const app = express();
...
app[url_data.methods](url, (req, res) => {
vailedHandle(url_data.vailed, url_data.methods === 'get'?req.query:req.body, url_data.mock(), res);
});
...
//project mock
const index = {
'xxx/getUserInfo': {
mock: () => {
return mock.mock({
code: 0,
data|1-9 :[{
'nickname|5-8': /[a-zA-Z]/,
'age|0-99': 20
}]
}),
...
}
}
}
由于最近學習了一丟丟node相關的知識哦，正好就可以練練手了~ 通過express和mockjs組合，在另外一個端口實現一個本地服務器，通過請求本地服務返回對應接口實現模擬數據，由于我們只需要接口，邏輯什么都不必管，所以只需要在mock的數據里面修改一下就能拿到需要的數據并且不必擔心影響原本項目，是不是瞬間覺得高端了不少，具體api接口內容和鏈接 其實可以通過node爬去你們的api文檔的內容自動生成，也可以通過自己封裝返回請求的邏輯實現報錯管理，感覺各種優化下去的話自己實現一個mock平臺也好像可以哦！
總結
個人感覺方案3 和 方案4 都是很好的實踐方法，而且對于代碼的組織和和管理都很方便，作為專業的搬運工，在別的項目中也只需要copy一份封裝好的代碼改改url又是一個嶄新的項目了哦~ 并且既然上一個項目已經通過qa測試那么代碼肯定是安全的~可以放心服用，當然了如果有追求的話也可以把這份代碼做的更加通用，用更好的方法去統一調用那就棒棒噠
嗯，當然這只是在這一年工作碰到的在聯調上的問題和一些總結，因為最近聽了某個live的雞湯就想寫寫文章，也算是對自己知識點的一些些總結，如果有更好的方案或者有不對的地方歡迎指出來~
