? 最近在項目中經常遇到軟件版本升級后不兼容舊版本的問題，本文根據以往經驗，從軟件接口設計、實現等方面整理了一些兼容性設計思路。

1. 優化設計

1）接口返回值的定義

有的人喜歡用0、1等較小的數字標記返回碼或其他一些常量含義，比如我接觸過幾個項目，使用整型常量0作為成功的返回碼，在以后的使用中，可能遇到的問題是整型的缺省值為0，這種情況下邏輯上無法區分沒有返回值還是返回了0，如果某天出現了此類問題，也很隱蔽很難排查。一旦這些常量定義下來，想要修改的代價會非常大或無法修改。所以，在定義這些常量時，要盡可能的考慮到各種可能的情況，不防將數字寬度放大點，預留出擴展空間。

2）版本號處理

初始設計時，應當在消息中保留版本號字段。這樣一來，當未來需要做出重大設計改變時，還可以通過引入新的版本號，來實現對舊版本的兼容。當收到消息時，首先通過版本號區分出消息的版本，按照版本號對應的效果處理，從而實現兼容。

3）客戶端分類

服務端通常需要接收不同終端發過來的請求，如APP、微信、網頁端、cs客戶端等。設計者不得不考慮的問題是在初版本中功能、實現可能都完全一致，但是不能保證未來有些客戶端需要區別對待。

有些設計者會針對不同的客戶端同樣的功能分開處理、實現多次的設計方式，這種方式固然清晰，相互之間不影響，但帶來了代碼、工作量的冗余，初版本實現需要寫多份，升級修改時也需要修改多處，代碼維護效率低，程序員的時間是寶貴的，并且這種方式生成的成果物也是臃腫了很多。雖然如此，也比完全不考慮調用者差異性要進步了很多。

這類問題，加上調用者的類型就能很快解決此問題了，如增加platForm參數，定義常量如“weChat”、“app”、“web”、“cs”、“others”標記就能輕松解決了，遇到需要區別對待的客戶端可能以最快的方式處理。

4）新增參數

在軟件開發時，不可避免的會遇到新增接口參數等問題，如果在新版本的接口中暴力的增加了必填參數，就需要所有調用此接口的老客戶端都需要重新改動，新舊版本完全不兼容。

對于新增參數，設計者應處理為舊版本非必填參數，結合版本號在新版本可以設置為必填。而對于那些未設計版本號的接口，一定要非必填。

2. 優化實現

1）新增參數

在軟件升級開發時，不可避免的會遇到新增接口參數等問題，對于新增參數，處理為非必填參數，可適當增加判空處理，必要時處理為缺省默認值。

?

?

如采用json傳參，針對值獲取，有以下幾種異常情況需要注意(適用于java開發)：

根據上述表格，不難總結出，判空使用json.get("param")最合適，故可參考如下代碼實現：

if(StringUtils.isNotBlank(json.get("param"))) {

???????? param= json.get("param").toString();

????? }else{

???????? //默認常量

???????? param= DEFAULT_PARAM;

????? }

2)參數類型發生變化

如果舊版本參數類型設計得不夠合理，或者隨著時間的推移，功能的升級，需要改變參數類型時，合適的代碼也是有辦法做到兼容的，比如：

人臉查詢或布控的相似度參數，最初的設計者只要考慮到值范圍為80-90（相似度80%-90%之間，傳參最小相似度80，最大相似度90）這樣的情景，采用整型傳參，隨著算法升級、應用場景更高要求等情況，出現80.5-90.5這樣的應用需求，代碼可這樣處理，先轉字符串再轉換為需要的類型：

Double.parseDouble(json.get("similar").toString())

在版本升級時采用上面方式處理之后無論接口傳參為整型還是浮點型都能夠正常接收，實現版本兼容。

????3. 總結

? 本文總結了一些項目開發中的經驗，提出的設計思路和實現方式都很簡單，還有其它的設計思路、好的實現方式有待補充。謀事在人，關鍵在于設計者和開發實現者考慮問題的全面性。

? 優秀的軟件設計會放遠目光，考慮到未來的發展方向，預留擴展空間；優秀的代碼是基石，就像建房子，設計稿畫得再漂亮，材料劣質，也是白白耽誤了設計成本。二者結合，高質量的設計，高質量的實現，必能提高效率，降低風險，避免無意義的重復勞動，事半功倍，以此共勉！

 

總結

以上是生活随笔為你收集整理的软件接口设计中的版本兼容问题处理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。