最近在專案中經常遇到軟體版本升級後不相容舊版本的問題，本文根據以往經驗，從軟體介面設計、實現等方面整理了一些相容性設計思路。

1. 優化設計

1）介面返回值的定義

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

2）版本號處理

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

3）客戶端分類

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

我遇到過針對不同的客戶端同樣的功能分開處理、實現多次的設計方式，這種方式固然清晰，相互之間不影響，但是個人認為，無意義的複製貼上能避免還是避免吧，初版本實現需要寫多份，升級修改時也需要修改多處，程式碼維護效率低，程式設計師的時間是寶貴的，並且這種方式生成的成果物也是臃腫了很多。雖然如此，也比完全不考慮呼叫者差異性要進步了很多。

這類問題，加上呼叫者的型別就能很快解決此問題了，如增加platForm引數，定義常量如“

4）新增引數

在軟體開發時，不可避免的會遇到新增介面引數等問題，比如最近遇到的問題，新版本的介面中暴力的增加了必填引數，造成了所有呼叫此介面的客戶端都需要重新改動，新舊版本完全不相容。

對於新增引數，設計者應處理為舊版本非必填引數，結合版本號在新版本可以設定為必填。而對於那些未設計版本號的介面，一定要非必填。

2. 優化實現

1）新增引數

在軟體升級開發時，不可避免的會遇到新增介面引數等問題，對於新增引數，處理為非必填引數，可適當增加判空處理，必要時處理為預設預設值。

如採用

根據上述表格，不難總結出，判空使用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. 總結

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

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