這項服務的用途
- 決定既有資產要保留、包裝還是替換
- 在 UI、通訊、背景處理、日誌之間劃分責任
- 設計 COM / ActiveX / C++/CLI / .NET 之間的邊界
- 規劃 32 位元 / 64 位元限制要在何處吸收
- 在棘手的缺陷調查開始之前，釐清應該先觀測什麼
適合的專案階段
- 開始實作之前
- 風險較高的升級或維護專案開始前
- 目前結構令人痛苦，但整個重寫又仍太沉重
- 反覆處理缺陷後意識到應該先整理架構本身
常見的討論主題
- Windows 應用程式架構
- COM / ActiveX / OCX 的處理方式
- 32 位元 / 64 位元互通
- 執行緒模型與生命週期設計
- 日誌設計、例外設計、異常案例測試
典型的進行方式
- 首先釐清目前的結構、限制以及具體的痛點。
- 接著區分出應該保留、包裝、替換的部分。
- 有必要時再延伸到實作取向的審查，或寫成書面的現代化計畫。
特別有效的專案類型
小村軟體有限公司特別擅長 略顯老舊且略為複雜的 Windows 專案：
- 仍有具價值的既有資產
- 目前結構難以維護
- 但整個重寫還不切實際
這類情境下，架構先釐清清楚，後續寫程式的效率通常會更高。