上一篇文章，我談到怎麼確認一個功能真的做好了，而不只是剛好成功一次。

不過，即使新功能本身通過測試，還有另一件事需要確認：把它放進微光之後，原本能用的東西，還會不會正常？

新功能通常不是獨立存在的。

它可能使用既有的帳戶、金幣、背包或權限，也可能和其他功能共用程式與資料。修改其中一個地方，看起來只是為了增加一項能力，影響卻可能延伸到原本沒打算碰的部分。

所以，在想「怎麼加進去」之前，我也需要想好：哪些東西必須維持原樣，以及如果出了問題，要怎麼停下來。

新功能的起點，是有人正在使用的日常
對我來說，新功能很容易成為注意力的中心。

我知道它能帶來什麼，也期待把它做出來。但對原本的使用者而言，他今天可能只是想完成和平常一樣的事情。

查看帳戶、領取獎勵，或使用一個已經熟悉的功能。

他不一定知道背後正在更新，也沒有理由為了我正在做的新東西，承受原本功能突然不能用的結果。

這讓我需要換一個角度看修改。

除了新功能有哪些要求，也要列出原本不能被破壞的行為。既有指令還能不能使用？資料會不會改變？原本允許的操作，是否因為新規則被意外擋住？

維持這些日常，也是開發工作的一部分。

先找出它會碰到哪些地方
如果只看新功能的畫面，容易低估影響範圍。

例如，新增一種商品，看起來可能只是多了一個購買選項。但背後可能需要調整價格資料、扣款流程、交付方式，以及背包顯示。

其中有些部分，也被其他商品使用。

因此，我想在修改之前，先找出它會經過哪些共用部分，以及哪些舊功能也依賴它們。

不一定每次都要畫出很大的架構圖，但至少能說清楚：這次改了什麼、沒有改什麼，以及哪些地方需要一起驗證。

如果發現為了一項小功能，必須同時大改很多地方，就值得停下來重新拆分。也許可以先做一個影響較小的版本，不必一次把所有想法都放進去。

測試環境，不能只是名字不同
我希望新功能先在隔離環境裡確認，而不是直接拿正在使用的服務試。

但隔離不只是換一個資料夾，或把畫面標成「測試版」。

如果測試程式仍然連到正式帳戶資料，或使用能對外發送訊息、發放獎勵的憑證，它仍然可能影響真的成員。

所以，需要確認測試使用的是什麼資料、連到哪個服務，以及能產生哪些效果。

可以使用合成帳戶與測試用資料，讓測試能重複執行，又不必碰到私人內容。確實需要驗證外部介面時，也要限制在明確的測試範圍裡。

我想要的隔離，是即使測試做錯了，也不會順手扣到某個人的金幣，或在正式頻道發出一排測試訊息。

新的要測，舊的也要再走一次
新功能通過測試，不代表共用部分沒有受到影響。

因此，除了驗證新增行為，也要重新檢查相關的舊流程。這類檢查通常稱為回歸測試，確認原本成立的事情，在修改後仍然成立。

假設增加了新的獎勵方式，就不能只測新任務能不能發獎。原本的獎勵是否仍然正確、重複領取是否仍被擋住，也需要確認。

需要檢查多少，應該依照實際影響範圍判斷，而不是永遠全部重做，或永遠只測新增部分。

如果改動碰到共用的帳務或權限流程，檢查範圍自然要更廣。若只是修改一段不影響操作的說明文字，就不需要假裝它和交易邏輯有相同風險。

重點是能解釋選擇，而不是只靠習慣。

能不能先讓少數情境使用？
如果功能適合，我會傾向先限制啟用範圍，觀察實際情況，再逐步擴大。

例如，先在測試頻道或事先同意的參與者之間使用，確認操作與回應都符合預期。

這不表示可以把尚未完成的基本檢查，丟給第一批使用者承擔。小範圍使用是為了發現環境與操作上的差異，不是替代前面的測試。

而且，畫面只對少數人開放，也不一定代表影響真的被限制住。

如果背後已經修改所有人共用的資料格式或帳務流程，其他成員仍然可能受影響。因此，限制入口之外，還要確認資料與操作效果的範圍。

我希望所謂的小範圍，是出問題時真的能控制影響，而不只是看見按鈕的人比較少。

暫時關掉新功能，應該能保住其他事情
增加功能時，我也想先安排停用方式。

如果上線後發現異常，能不能先停止新的操作，讓其他服務繼續使用？還是只要出問題，就得把整個 Bot 一起停掉？

能分開停用，通常比較容易處理。但停用也需要考慮正在進行中的事情。

有人已經提交的內容怎麼辦？正在等待交付的購買，還要不要繼續處理？不能只是讓按鈕消失，就把中途的操作一起忘掉。

我希望停用能阻止新的風險，同時保留足夠資訊，把已經開始的事情查清楚並妥善收尾。

這也是為什麼處理狀態與操作紀錄，不能等出問題之後才想到要加。

退回舊程式，不一定能退回所有變更
想到更新失敗，最直覺的補救方式是把程式換回舊版。

但如果新版已經改過資料，舊版未必讀得懂；如果更新期間產生了新的交易，也不能直接把整份資料還原到更新前，假裝那些操作沒有發生。

那可能會把成員真的完成的事情一起抹掉。

所以，我需要把程式和資料的退回方式分開考慮。

哪些變更可以安全撤回？哪些只能停止繼續發生，再另外修正？舊版是否仍能讀取目前資料？需要恢復備份時，怎麼處理備份之後新增的紀錄？

有備份很重要，但備份本身不是所有問題的答案。真正需要的是一個知道會保留什麼、失去什麼，以及怎麼核對結果的恢復方式。

如果某項變更很難逆轉，就更應該在執行之前確認，而不是等到出事再找退路。

通過測試，和允許更新，是兩個決定
一個版本準備好了，不代表現在就是適合更新的時間。

可能有活動正在進行，也可能有尚未結束的操作。更新是否需要短暫中斷、誰來確認結果，以及出問題時誰能處理，都會影響安排。

因此，我想把「這份修改是否符合要求」和「是否在這個時間套用到正式服務」分開看。

前者需要測試與審查，後者還需要確認當下狀態與影響範圍。

而且，真正更新的內容，必須是先前驗證過的那一份。不能在最後一刻又順手加上幾個修改，卻沿用原本的測試結果，認為全部都已經確認。

更新完，再看一次使用者真正會走的路
程式成功啟動，只代表它開始執行，不代表功能已經正常。

更新之後，仍然需要確認重要入口能否使用、相關資料是否能讀取，以及基本流程是否符合預期。

檢查方式也要避免製造新的正式副作用。能用唯讀查詢確認的，就不隨意做真實扣款；需要測試操作時，使用事先安排的測試範圍與帳戶。

如果發現異常，依照原本設定的停止條件處理，而不是因為已經更新，就硬撐著繼續開放。

同時，也要留意那些沒有立刻造成錯誤、卻讓使用變得困難的改變。例如，入口移動之後找不到了，或原本熟悉的操作多了一個沒有說明的步驟。

技術上沒有報錯，不表示成員的日常沒有被打斷。

讓新內容加入，而不是讓所有人重新適應一次
我想持續替微光做新東西，也希望它能慢慢變得更有趣。

但增加內容的速度，不應該只看我能多快完成程式。還要看能不能在保留既有體驗的情況下，把變更安全地放進去。

先了解影響範圍，在隔離環境裡確認，保留停用與恢復的方式，再核對正式更新後的結果。這些步驟可能不會出現在功能介紹裡，卻會影響成員能不能放心使用。

我希望大家某天進入微光時，發現多了一件可以試試看的事情。

而他原本想做的那件事，仍然好好地在那裡。