為何軟體開發要做向下兼容

平常在使用應用程式時，或許你經常會聽到為什麼改版後，舊的功能就不能用了，或者是系統要求你更新，否則就無法繼續使用。這種情況下可能就缺乏向下兼容性。

什麼是向下兼容

向下兼容（Backward Compatibility）是指軟體開發在新版本中新增功能的同時，依然保持對舊版本的兼容性。

目的是確保軟體的穩定性及可靠性，同時也能夠留住更多的用戶。

這邊就要講到之前讀的 Clean Code 的 SOLID 原則，還記得嗎？

這個原則基本上就是在談「改變」帶來的「副作用」該如何應對，但軟體更新是必然會發生的，所以開發過程中要如何確保舊有的功能不會被破壞，也就是我們在講的「Breaking Change」，正是向下兼容需要面對的課題。

總不能我軟體一更新，結果原本還使用得好好的用戶，突然都無法繼續使用了，這樣誰會想用呢～

不過向下兼容不只是讓舊版本還能繼續使用而已，它其實在整體軟體開發流程中扮演了維繫信任與穩定性的重要角色，這邊從幾個常見的面向來看。

你可以想像一下，你是一名 APP 的用戶，早上一如往常地打開 APP，結果卻發現無法登入或是操作介面跟以往完全不同，這時候腦中一定閃過很多「這是什麼鬼」、「這個 APP 怎麼了」、「現在是要怎麼用」等想法，這時候你一定會覺得很煩躁，甚至想要砍這個 APP。

而向下兼容的存在，就是為了避免這種「突然的變動」帶來的使用者流失與反感。

如果每次更新都破壞舊有的功能，開發團隊就得再花上更多時間去處理回報的錯誤、修復 Bug，甚至是 Revert 回舊版本，這樣不僅會增加客服的業務量、軟體的維護成本，也會降低開發效率。

但相反的，如果能維持對舊功能的兼容，那系統的開發或更新就能更平穩，也讓團隊能夠更專注在開發有價值的新功能。

不是所有使用者都能在第一時間升級到最新版，特別是企業級的用戶，其內部系統、硬體設備或作業環境通常會綁定在某個特定版本，如果貿然升級可能伴隨許多風險。

而向下兼容的設計，能讓這些用戶在過渡期間保持系統穩定運作，提供足夠的時間進行評估、部署，進而降低升級的阻力。

通常能夠向下兼容的軟體，相對更容易建立正面的品牌形象與用戶信任，也代表著這個產品具備長期演進的可行性，不會因為某次的更新就讓人「一試成主顧」或是「一怒棄坑」。

因為範圍太廣，這邊就以前後端為主的電商平台或 ERP 系統來說好了

當資料 schema（例如：商品欄位、訂單狀態、客戶資訊）有改動時，如果設計時沒有 handle 好，舊系統可能會無法處理新欄位或是因為缺少欄位而發生錯誤。

通常 ERP 系統或電商後台如果進行重大 UI/UX 改版，用戶會需要一段時間適應。

介面結構大改時，可以盡量保留舊操作路徑或瀏覽動線，用戶就不需要花太多時間適應。
提供新舊版本 Toggle 機制，讓用戶可以選擇要使用哪個版本，像是過去 Microsoft 365 或 Google Workspace 在介面大改時，會在右上角提供「切換回舊版」按鈕。

在設計的時候應該要考慮模組化，這樣在需要進行一些有 Breaking Change 的改版時，可以更容易解耦將功能拆開，且不影響到其他功能。

主要是為了避免更新系統時一次全部替換，也減少錯誤風險。

使用 Feature Toggle 控制新功能的開關。像是用 .env 來控制是否開啟新功能。
使用 Canary Release 漸進式部署，先在部分用戶中測試新功能，確認穩定性後再逐步擴大範圍。
你可以根據地區﹑平台或使用者等級來評估是否對部分用戶開放新功能（灰度發布），觀察是否有出現不兼容的問題。
提供 rollback 機制，以便在系統出現問題時，只需要關掉 feature toggle、或 revert 回上一版，就能讓系統回到正常穩定的狀態，不會影響到其他用戶。

不管開發什麼軟體，向下兼容都是很重要的一環，不僅能夠保護使用者體驗，降低技術債與維護成本，還能夠支援過渡期，建立產品長期可持續性。

畢竟，不是每個人都能夠很快得適應，也不是所有設備或系統都能馬上升級。

所以不管是透過版控、保留資料欄位、介面的切換，還是用一些像是 Feature Toggle 或漸進式部署的方式，目的都是為了讓更新變得更平順，而不會一改版就讓用戶「崩潰」。

口語上來說，向下兼容就像是在講：「放心，我們更新後，你依然可以照你習慣的方式使用」這樣才是對使用者最友善的做法，也是一個好的產品該有的基本態度。