一個老系統的生死狀

公司內部基於 .NET 架構所開發的各式系統，多半已有 8～9 年歷史。這些系統一開始交接時，來自不同的「生父生母」或「後父後母」，本身早已累積大量技術債。每當接手一個 Bug，幸運的話只需微幅修改便可止血；倒楣的話可能不知不覺剪到了靜脈，等到使用者打來才驚覺災情已發，這時只能趕緊翻出主機上那個尚未覆蓋的備份 ZIP 檔，以最快速度退版，讓系統得以繼續苟延殘喘。

在殘酷現實中尋找一線生機

Bug 修起來尚可控制，最令人頭痛的是接到新的業務需求，這些需求若強加在舊系統之上，常因架構限制而舉步維艱。曾經我接手一套系統，花了一週時間都無法在本機編譯與偵錯，才發現它依賴特定第三方外掛工具與 IIS Proxy 環境，而我基於公司政策無法安裝 Server 軟體，只能生出一個測試環境來支援開發，這樣的現實可謂殘酷至極。
還有令我為之驚艷的紀錄系統運作 log 機制，初期我發現 log 裡有許多看似來自其他系統的紀錄，一查之下才發現：原來所有應用系統的 log 全都寫入同一個檔案中，光是過濾雜訊就得花上許多時間。這些日復一日的維運痛苦，早就讓我們這群「繼父繼母」萌生出全面翻修的念頭。

危樓上的疊加：傳承困境與技術斷層

除了系統老化，最難解的是人員更迭造成的知識傳承斷層。過去我們並沒有正式的知識管理系統（KM），幸運點或許能拿到一份前輩留下的「交接包.zip」。但即使有完善的版本控制工具，單純記錄程式差異仍無法重現設計背後的業務邏輯與決策脈絡。
許多開發人員面對這樣的系統，要嘛選擇「不動則不會出錯」，要嘛索性「另起爐灶」，避免動到前人程式碼。久而久之，系統愈加疊床架屋、違章建築不斷疊加，終至成為讓人想問「到底是拆還是修」的殘破危樓。
更棘手的是每個系統採用的技術架構各異，取決於當初開發者或委外廠商的習慣與專長，缺乏統一的技術方向與標準。就筆者自身經驗而言，即便是熟悉的 .NET 系統，從上手到能修改約需半年，若要開始開發新功能，至少也需八個月的磨合期。高門檻的交接成本，導致維運仍須仰賴特定資深人員，備援制度難以落實。

專案的前世今生：從問題到轉機

承前言提到隨著微軟終止支援的公告發布，組織意識到大量老系統需要翻修升級。雖然委外開發速度較快，但過往困境仍可能重演──翻修完後仍得靠內部人員維護。因此，我們幾位資深同仁決定從頭打造，透過技術轉型期望翻修不只是「重寫」，更是「重構整個開發與維運的模式」。
我們設定了幾個明確的目標：

1. 完整保留開發與維運知識，避免再出現傳承斷層
2. 建立可複製、標準化的開發架構
3. 透過協作實踐，摸索出組織內最適合的開發模式
4. 引入自動化腳本與 DevOps，強化部署穩定性
5. 讓成員在實戰中學習新框架，完成技術轉型
6. 提升 UI/UX 的使用者體驗，建立口碑

怎麼挑選第一個「翻修口碑案」？

我們一致認為第一案不能失手，需兼顧訓練、交付與口碑三者。理想的目標系統應具備以下特性：

1. 功能複雜度適中：需有登入、查詢、異動與簽核功能，但業務邏輯不宜過於繁瑣

2. 使用者數量控制在 100～200 人：便於需求收斂，避免初期技術負擔過重

3. 有感的 UIUX 改善：若能在視覺與操作上明顯提升，能強化對新架構的信心

經過篩選，我們選定了「資訊資產系統」作為口碑案。該系統紀錄公司各類資訊設備（如伺服器、網路設備等），主要由系統管理員登錄並定期盤點。使用者大部分為資訊部門的同仁，需求溝通門檻相對較低；系統本身歷史悠久、架構雜亂，具備高度重構價值。

聊聊團隊的組成

本次專案的核心並非「交付」而是「練功」。因此，我們採用半志願制，讓部門同仁根據自身負荷與意願加入。令人驚喜的是，多數科內的同仁都有興趣，他們早已被舊系統折磨得技癢難耐，以下是我們的開發小隊成員主要結構：

雖然PG配置較多，PM&SA 為一人擔任，但加入的同仁大部分皆具備系統分析與開發能力，雖然初期需花時間學習新技術，但後期開發效率明顯提升。最關鍵的是：有默契、能快速溝通、也能接住多工角色切換。

Ending Remarks：打造可複製的開發模式

老系統的挑戰不只是技術問題，更是知識傳承與團隊協作的考驗。透過半志願制的分時參與模式，展開系統重構，也打造出一套可複製、標準化的開發與維運模式。未來，這套模式將幫助組織在面對新需求或技術轉型時，更具彈性與韌性；不再依賴單一資深人員，而是形成「多點參與、協同維運」的團隊文化。

老系統曾是危樓，如今透過團隊合作與技術轉型，我們將它轉化為可持續發展的資產，這只是開始，Let's Go ! 夥伴們。