1.開發規範-- 常用的版本控制常用的版本控制

這裡版本控制是經過筆者在項目中實踐總結得出的,有比較廣的适用範圍, 當然也要根據不同的業務有取舍應為筆者水準有限,其中有不足的地方也 往大家指出,多多交流

對于大版本控制就是所謂的在url裡面進行控制,舉個例子:

在這裡比較推薦第二種因為參數控制可以留到更小的版本進行控制,如果是第一種需要在多傳遞一個版本參數會顯得很累贅

一般大版本控制基本上是對第一位和第二位進行控制可以根據業務需求進行取舍

對于小版本控制存在的意義在于,在一次疊代中接口改動很小但是有個别接口有輕微的邏輯變化,比如:

例子如下:

先聊聊由什麼引出了了大小版本控制,之前筆者在開發一個項目的時候版本疊代基本上是一個星期一次,為了配合端進行了最簡單的 版本控制(分檔案請求位址的控制)後來發現到後面一次性要維護,3到5個版本而且真正上的邏輯差别都不大,隻是為了做到配合端做好 版本控制,後來意識到這種方式在這種快速開發中是不可取得,在後面的了解和探索中發現了大小版本控制比較适合.

接着我們說能真真解決什麼問題:

從上面的例子筆者相信大家可以看出,如果有一次更新疊代隻擁有大版本控制的項目是不是需要在建立一套項目,當然是肯定的,到後 面的開發中進過的版本疊代越多,需要維護的版本就越來越對,如果有一天很早之前一個接口曝出了bug那是不是這個版本之後的所有 隻要是繼承了這個方法的項目都要改,如果都已經上線了進行着一系列修改的風險比較大,應為動刀的項目比較多,能夠縮小這一問題 的比較好的方法就是把能相容的版本盡量的相容,但是又要做到靈活,那麼小版本控制是一個非常好的方法.

其實在市面上流行的還有一種做法,一套項目相容所有版本,大家也可以自己考慮一下這種方法的可行性,當然莫些業務需求會用到, 但在這裡并不推薦使用,這樣做的問題在于對于一個接口的邏輯在後期會相當複雜難以維護,筆者公司之前交給外包公司做的一個項目 就是采用這種方式,到後面實踐下來暴露了很多很多的問題.

在這裡筆者也進行了一些梳理,在什麼時候進行相容,在什麼時候進行版本切分,可以提供給大家參考參考:

例子:

對于app端要差別對待,分别為以下幾大點:

對于不同的疊代版本采用以下規則進行(相容)或(區分項目)操作:

以下情況進行相容操作:(所謂相容就是多個版本請求同一個位址傳遞的version不同,代碼層面的區分業務邏輯)

以下情況進行區分版本:(所謂區分版本就是調用的連結本質上的不同指向的項目差別對待,項目層面區分業務邏輯)

在這裡這篇簡短的版本控制說明就到這裡,希望大家能從中收獲到一些靈感,但是請注意務必根據業務請求結合實際.