許多企業最終都會面對一款無人積極維護的應用程式。最初的開發人員或代理商已經離開，版本發布已經停止，應用程式商店在提示 SDK 過時，也沒有人有把握去修改程式碼。人們的直覺往往是要不繼續打修補，要不就砍掉重練。但這兩種做法都不應憑直覺決定。本應用程式救援指南說明如何評估一款廢棄的應用程式，並依據證據而非挫折感，在重構現有程式碼與重新打造之間做出選擇。
服務簡介
應用程式救援首先要弄清楚您實際擁有什麼。這代表要恢復對原始碼、建置設定、簽署金鑰、代管帳號、應用程式商店頁面與第三方服務的存取權限；接著審查程式碼結構、相依套件、測試涵蓋率與已知缺陷；再檢查該應用程式能否在目前的作業系統版本上建置與執行。重構是指在原有程式碼庫的基礎上加以改善：更新相依套件、修正缺陷、重組問題區域並補充測試，同時讓應用程式維持正常運作。重建是指撰寫新的程式碼庫，通常會盡可能沿用設計、資料與後端服務，並將使用者移轉到新版本。重構能保留以往的投入，避免長時間無法發布。當程式碼庫難以維護、建立在過時的框架上，或與產品目前的需求存在根本性落差時，重建可能是更好的選擇。答案往往是兩者結合：先立即穩定，再逐步替換部分模組。
適用對象
本指南適用於：
- 應用程式開發人員或代理商已無法繼續提供服務的企業
- 應用程式無法建置、在新裝置上當機或面臨應用程式商店退件的產品負責人
- 從前任團隊手中接手半成品應用程式的創辦人
- 正在決定是否繼續投入現有程式碼庫的團隊
有助釐清的問題
結構化評估有助於釐清：
- 您是否完全擁有並能存取程式碼、金鑰、帳號與資料
- 現有程式碼中有多少是可靠的、有多少存在風險、又有多少缺漏
- 所用框架與相依套件是否仍受支援
- 哪條路徑（重構、重建或分階段替換）符合您的時程與風險承受度
包含內容
- 恢復存取權限：原始碼儲存庫、建置檔案、簽署憑證與金鑰庫、雲端與代管帳號、應用程式商店帳號以及第三方 API 金鑰
- 確認程式碼及任何授權的法律所有權，必要時諮詢您自己的顧問
- 檢查應用程式能否從原始碼建置，並在目前的作業系統版本上執行
- 審查相依套件中是否有過時、不受支援或有漏洞的函式庫
- 評估程式碼結構、測試涵蓋率與文件
- 列出已知缺陷、當機報告、使用者抱怨與應用程式商店警告
- 梳理應用程式所仰賴的後端、API 與資料
- 從投入、風險與無法發布的時長等面向，為重構、重建或分階段替換等選項評分
- 在進行更大規模的工作之前，約定處理緊急問題的穩定方案
不包含內容
- 宣稱能找出或解決每一個遺留問題
- 超出已確認復原範圍的新功能開發
- 正式的安全評估或滲透測試，除非另行確定範圍
- 關於程式碼所有權或與前供應商糾紛的法律建議
適用時機
當應用程式已無法安全發布、平台要求即將使其不符合應用程式商店規範，或每一次小改動都會引發新問題時，就應採取行動。不要等到應用程式被商店下架或某項關鍵服務停止運作時才行動。如果您無法存取原始碼或簽署金鑰，請先解決這個問題；沒有它們，無論程式碼品質如何，重建都可能是唯一的選擇。
我們的方法
從存取權限與證據著手，而不是從看法著手。許多廢棄的應用程式一旦能重新建置，情況往往比看起來要好；另一些應用程式看似正常，卻建立在已不可行的框架之上。請依據一份涵蓋程式碼、相依套件、基礎設施與產品需求的書面評估做出決策。我們的 App Rescue & Rebuild 服務涵蓋評估與復原：恢復可正常運作的建置、穩定關鍵問題，並建議與執行已確認的復原路徑，同時提供範圍明確的復原紀錄與交接資料。如果問題延伸到範圍更廣的平台、後端或舊有系統，Platform Rescue & Modernisation 服務可提供現況圖、穩定方案與現代化路線圖。復原之後，請規劃持續維護，避免應用程式再次陷入同樣的狀態：定期更新相依套件、建立發布流程，並明確帳號與金鑰的歸屬。
常見問題
相關文章
立即開始
手上有一款無人能維護的應用程式？
請告訴我們您目前能存取哪些內容、哪些功能出了問題，以及應用程式接下來需要做到什麼。我們將提出書面評估與復原範圍。
申請書面範圍說明