升級機制的設計之難

我們在設計系統（例如，軟體產品）的時候，往往光是考慮眼前的需求跟限制，就已經焦頭爛額。

不過系統是有生命的。軟體有版本，書籍有版次。在理想的世界中，每一個版本都在小心策劃後推出，而所有的使用者（終端消費者、接受方）也跟隨著升級：

很不幸的是，真實世界往往比這個模型複雜多了。尤其如果當系統是分散地傳播給每一個終端使用者（例如，每個人機器都裝一份），就會發生下圖的情形。尤其如果供應的一方（軟體開發銷售商、系統提供方）的政策是不保留舊版本的庫存──這往往有現實不得不然的理由，例如倉儲成本──那麼仍然在使用版本 V₁ 的人，就只好直接升級到 V₃。任何沒有考慮到這條升級路徑的系統，就等著看災難發生了。

雖然「免升級」一直是 web app 的重要訴求（相對於桌面軟體），但是大家不要忘了，如果不是使用者要升級，複雜度就會落在提供方這一邊。另一方面，如果終端使用者有一份匯出資料，或是任何必須持有在使用方的子系統（文件資料也是一種系統，受到例如文件格式的制約），那麼資料格式也會有升級的問題。所以即使是 web app 也跳脫不了系統的本質。

如果使用者甚至有降級的自由，問題就更複雜了。升級路徑就得考慮到降級後再升級的可能性。

修正套件 (patch，也有地方做「補丁」)、維修包、維護套件，或者像軟體業者用的 "service pack" 一詞，作用在於修正、彌補系統的缺陷，或是添加、延伸系統的功能。雖然說我們盡可能想像，一個版本跟另一個版本之間的差別，中間隔著的就是這些修正（也就是說，版本 V₁ 增添了修正 P_1.1, P_1.2, ... P_1.n 後，就應該變成版本 V₂），但實務上往往不是這樣。

假定我們只允許向上升級，同時只允許在大版本間的跳躍式更新（也就是說修正套件只能一版一版升上去，不能跳過去），那麼在下圖有三個版本、三個修正套件的情況下，所有可能的升級途徑就有 12 條。升級路徑數在這種情況下會隨著版本/修正套件數量增加而呈指數成長。所以升級機制的設計、測試當然是一件可怕的事情，因為這套機制在本就已複雜的系統外圍，創造了另外一種複雜性。