資料介面設計中遺漏的版本差異

2023年03月05日 22:22:00

我們在考慮資料介面的設計的時候，最容易關注的是資料本身的介面。簡單點說，要哪些資料，我介面設計的時候就加入那些資料。在此基礎上再考慮資料結構以及結構優化。

這些並沒有什麼問題。事實上，也只有考慮這些，介面才可以基本工作起來。不過，乙個設計好的介面會比一般的介面多注意一些因素，一些以後可能發生變化的因素。在好的介面中，有些介面，一直不需要修改；有些介面修改了也和原有介面相容。

乙個介面一直都不需要修改，一般有兩種情況：需求永遠不變化；介面設計地太好了。我們幾乎不敢說自己的介面設計地太好了，以致於可以肯定以後不會修改，於是我們不得不面對需求變更的問題。

對於軟體a1和軟體b1，他們之間定義了介面f1。當需求變化後，如a公升級到a2，b軟體公升級到b2，介面也變成f2。如果我們只考慮軟體a2和b2，那麼當然沒什麼問題，f2完全可以執行。

隨著軟體的複雜度提高，各種執行環境我們也開始必須考慮到。對於本案例中，我們應該關注a1、b1、a2、b2可能同時存在的情況，那麼我們必須考慮a1和b2以及a2和b1的情況。如果版本更多，其中間的複雜度越高。

在業務編寫中，相對於高版本來相容低版本的**還是可以編寫出來的，因為它已經知道低版本的存在了。可是低版本如何相容高版本之間呢？更何況，就算高版本能夠相容低版本，也容易讓人對這類介面變得頭疼。

在《跨越邊界: rails 遷移》中，針對rails中的migration做了一些比較深入的**。其重要資訊在於，rails中在資料遷移的時候，做了migration記錄。這樣，程式可以根據這個記錄進行遷移資料。

這真是本文重點要提到的，資料介面設計中，應該包含版本差異資訊。

簡單點說，對於介面f1和f2來說，假設f2是f1的公升級版本，那麼f2在設計的時候必須考慮如何和低版本的f1相容。設計師必須將其中的差異寫入進介面資訊中。

一般情況下，我們的介面變更多為：增加新錶、增加新字段（我這裡簡單地用表和字段來描述資料。針對不同的儲存格式，有不同的叫法）。很少有刪除欄位和刪除表的。修改字段型別的做法雖然存在，但更是少之又少。

針對上面的變更，其實都可以找到一種方式來描述這些差異。一旦我們定義好這些差異，不管舊版本的程式還是高版本的程式，都可以通過這些差異來獲取到自己所需要的資料。就算f1和f2已經不相容，我們在介面資訊中將不相容的資訊寫進去，程式一下子就能發現，而不會在介面操縱到一半的時候，發生不可以**的錯誤。

好的介面設計必然也是規範的設計。將這種設計規範在公司內部統一起來，就可以在此基礎之上，設計出統一的接**換程式，這個程式能夠自動處理介面差異，可以想象，系統的相容性必然上乙個台階。

認真地考慮我們系統之間的相容性，將會給以後的維護減少很多任務作量。而既然考慮了相容性，就必須在介面設計的初期以及變更的時候，將前後版本的差異資訊加入。這才是乙個完整的設計。