nota.lukhnos.org

升級機制的設計之難

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

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

Why Upgradability Is Hard, Part 1: The Ideal World

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

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

Why Upgradability Is Hard, Part 2: By Passing One Version

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

Why Upgradability Is Hard, Part 3: Regression and Downgrading

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

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

Why Upgradability Is Hard, Part 4: When Patches Are Involved