資訊專欄INFORMATION COLUMN
摘要：版本升級(jí)每個(gè)文件方法頭標(biāo)明版本號(hào)，每次修改需修改版本號(hào)大于原版本號(hào)，即為版本升級(jí)。
這些天項(xiàng)目有的API出現(xiàn)版本控制問(wèn)題，著實(shí)忙乎了一小陣，因?yàn)轫?xiàng)目使用TP5的傳統(tǒng)方法進(jìn)行版本控制（api目錄下進(jìn)行版本區(qū)分，由請(qǐng)求路徑?jīng)Q定使用的版本）
但是問(wèn)題往往是，項(xiàng)目使用了v2版本,但是后端又新建了v3，而前端不知情，所以也趁著這次機(jī)會(huì)，探索了較為實(shí)用的前后端分離問(wèn)題與解決方案，并做整理。
較明顯的問(wèn)題1.后端 API 產(chǎn)能不免，供給不上的問(wèn)題
2.后端 API 出現(xiàn) BUG，需要等待修復(fù)的問(wèn)題
3.前后端溝通差異導(dǎo)致API實(shí)現(xiàn)的偏差
4.后端 API 發(fā)生了修改，沒(méi)有通知到前端，showcase 的時(shí)候發(fā)現(xiàn)了 bug
1.后端規(guī)范功能函數(shù)集、功能模塊集、統(tǒng)一返回格式與方法、提高代碼復(fù)用率，從而提高后端API產(chǎn)能問(wèn)題
問(wèn)題2解決方案1.API出現(xiàn)BUG，前端提出BUG，并設(shè)置修復(fù)期限、BUG等級(jí)、修復(fù)獎(jiǎng)勵(lì)記錄
2.API從完成到正式使用有三天使用內(nèi)測(cè)期，內(nèi)測(cè)期內(nèi)前端發(fā)現(xiàn)BUG有獎(jiǎng)勵(lì)記錄
3.前端內(nèi)測(cè)期外的API出現(xiàn)BUG次數(shù)作限制，超過(guò)則懲罰記錄
4.后端內(nèi)測(cè)期外的API出現(xiàn)BUG次數(shù)作限制，超過(guò)則懲罰記錄
使用API敏捷原型開發(fā)方法：
--前端構(gòu)造理想IO，即參數(shù)，返回?cái)?shù)據(jù)格式等等(半天)
--后端思考實(shí)現(xiàn)可行性，調(diào)整IO(半天)
--后端實(shí)現(xiàn)API(協(xié)商時(shí)間)，鎖定API版本(具體實(shí)現(xiàn)參考下面方案)
實(shí)現(xiàn)一個(gè)簡(jiǎn)易型的消息系統(tǒng)（我們使用了基于swoole實(shí)現(xiàn)的websocket，具體可參考我的開源小框架）
1.后端
--API完成
--與前端確認(rèn)OK，則API鎖定版本V1.0（自動(dòng)記錄鎖定情況到日志）
2.需求變化/其他變動(dòng)
--解鎖API（自動(dòng)通知前端,XXAPI版本解鎖了），不解鎖則無(wú)法提交成功
--修改完成后更新API版本，重復(fù)步驟1即可
API版本解鎖：每個(gè)API文件方法頭標(biāo)明版本號(hào)，每次修改需修改版本號(hào)，即為解鎖。
API版本升級(jí)：每個(gè)API文件方法頭標(biāo)明版本號(hào)，每次修改需修改版本號(hào)大于原版本號(hào)，即為版本升級(jí)。
實(shí)現(xiàn)步驟1.所有API按特定模塊歸類，例如admin后臺(tái)模塊，在API目錄里編寫相應(yīng)的各個(gè)API文件，或如上圖進(jìn)行區(qū)分
2.記錄所有模塊API目錄的路徑到腳本，在開發(fā)人員提交的時(shí)候?qū)@些路徑進(jìn)行檢查
3.編寫檢查API的腳本，工作流程如下：提交時(shí)鉤子檢查API文件里的API方法是否無(wú)解鎖的情況下被修改，即提交的文件如果是API目錄下的API文件，則該文件方法注釋里的版本號(hào)是否與原函數(shù)一致，一致且函數(shù)內(nèi)容不一樣，提交失敗并提示
4.如果提交的API文件版本大于原版本，短信通知過(guò)前端，提交成功
提交代碼時(shí)共觸發(fā)兩個(gè)腳本，一個(gè)做檢查，一個(gè)做記錄（記錄前端人員的電話，API目錄）
以上為粗略說(shuō)明，若有錯(cuò)誤與更好建議，請(qǐng)留言反饋，謝謝。
創(chuàng)作不易，GitHub 右上角點(diǎn) Star 支持下吧，謝謝^_^
基于swoole的實(shí)時(shí)消息通信框架
基于Fastadmin整合阿里云OSS,Redis,物流，短信的后臺(tái)系統(tǒng)
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://www.ezyhdfw.cn/yun/29113.html
摘要：前后端分離的開發(fā)方式在最近幾年突然火起來(lái)，松哥認(rèn)為有兩方面的原因前端的發(fā)展。不變其實(shí)除了前后端交互方式發(fā)生變化之外，其他的地方都是不變的。 事情的起因是這樣的，有個(gè)星球的小伙伴向邀請(qǐng)松哥在知乎上回答一個(gè)問(wèn)題，原題是： 前后端分離的時(shí)代，Java后臺(tái)程序員的技術(shù)建議？ 松哥認(rèn)真看了下這個(gè)問(wèn)題，感覺(jué)對(duì)于初次接觸前后端分離的小伙伴來(lái)說(shuō)，可能都會(huì)存在這樣的疑問(wèn)，于是決定通過(guò)這篇文章和大家聊一...
摘要：前后端的界限是按照瀏覽器和服務(wù)器的劃分。前后端彼此互不關(guān)聯(lián)。關(guān)于作者本文部分圖片段落參考文章實(shí)踐中的前后端分離。淘寶前后端分離實(shí)踐本文源碼詳見(jiàn)服務(wù)端代碼。 一、起源 （故事純屬虛構(gòu)，如有雷同，純屬巧合）傳說(shuō)在很久很久以前，我們有志之士有了個(gè)創(chuàng)業(yè)的想法，于是乎開始了自己的創(chuàng)業(yè)之夢(mèng)，但是人手不足啊，于是乎所有角色老子一個(gè)人全包了： Roles: PM, DBA, RD, FED, Des...
摘要：前后端的界限是按照瀏覽器和服務(wù)器的劃分。前后端彼此互不關(guān)聯(lián)。關(guān)于作者本文部分圖片段落參考文章實(shí)踐中的前后端分離。淘寶前后端分離實(shí)踐本文源碼詳見(jiàn)服務(wù)端代碼。 一、起源 （故事純屬虛構(gòu)，如有雷同，純屬巧合）傳說(shuō)在很久很久以前，我們有志之士有了個(gè)創(chuàng)業(yè)的想法，于是乎開始了自己的創(chuàng)業(yè)之夢(mèng)，但是人手不足啊，于是乎所有角色老子一個(gè)人全包了： Roles: PM, DBA, RD, FED, Des...
摘要：什么是前后分離前后端分離并不是什么新鮮事，到處都是前后端分離的實(shí)踐。然而一些歷史項(xiàng)目在從一體化設(shè)計(jì)轉(zhuǎn)向前后端分離的架構(gòu)時(shí)，不可避免的會(huì)遇到各種各樣的問(wèn)題。搞了一個(gè)前后分離，需要分離部署。 探究 ：深入聊聊前后分離架構(gòu) 前后分離，一直是一個(gè)相當(dāng)泛泛的問(wèn)題，前后分離到底好不好？沒(méi)有絕對(duì)的對(duì)，沒(méi)有絕對(duì)的錯(cuò)，業(yè)界就這個(gè)問(wèn)題已經(jīng)激烈的探討幾年了.出現(xiàn)討論的點(diǎn)在于：分離當(dāng)然是好的,但是以什么樣的服...
摘要：什么是前后分離前后端分離并不是什么新鮮事，到處都是前后端分離的實(shí)踐。然而一些歷史項(xiàng)目在從一體化設(shè)計(jì)轉(zhuǎn)向前后端分離的架構(gòu)時(shí)，不可避免的會(huì)遇到各種各樣的問(wèn)題。搞了一個(gè)前后分離，需要分離部署。 探究 ：深入聊聊前后分離架構(gòu) 前后分離，一直是一個(gè)相當(dāng)泛泛的問(wèn)題，前后分離到底好不好？沒(méi)有絕對(duì)的對(duì)，沒(méi)有絕對(duì)的錯(cuò)，業(yè)界就這個(gè)問(wèn)題已經(jīng)激烈的探討幾年了.出現(xiàn)討論的點(diǎn)在于：分離當(dāng)然是好的,但是以什么樣的服...
閱讀 1803·2023-04-25 16:29
閱讀 1019·2021-11-15 11:38
閱讀 2344·2021-09-23 11:45
閱讀 1479·2021-09-22 16:03
閱讀 2608·2019-08-30 15:54
閱讀 1247·2019-08-30 10:53
閱讀 2661·2019-08-29 15:24
閱讀 1155·2019-08-26 12:25
