COBOL 遷移至 Go：英國企業指南

當簡潔性、快速建置與輕鬆部署比龐大的企業框架生態系更重要時，將 COBOL 遷移至 Go 是一個務實的選擇。它編譯為單一靜態二進位檔，沒有執行階段相依性，隨處可執行，其內建的並行模型天然適合將 COBOL 批次處理現代化為並行工作負載。

本指南闡述 COBOL 遷移至 Go 實際牽涉哪些內容、英國企業可採用的方法、成本幾何，以及您必須提前規劃的那一個精度問題。

摘要

• Go 適合那些看重簡潔性、快速編譯、單一二進位部署與輕鬆並行，而非厚重企業框架堆疊的 COBOL 遷移
• Go 沒有原生十進位型別：COBOL 壓縮十進位（COMP-3）欄位預設對應為 float64，因此金融運算需要一個十進位函式庫，例如 shopspring/decimal
• 三種主要方法（自動轉換、並行重寫與漸進式「絞殺榕」遷移）具有不同的風險與成本特徵
• 中等規模的遷移通常花費 200,000 至 800,000 英鎊，歷時 一 至 兩 年；十進位精度決策與資料存取層是關鍵的規劃事項

為何為 COBOL 遷移選擇 Go

Go 並非最大的企業生態系，但它是一門刻意為之、專注的語言，非常適合某些 COBOL 現代化情境：

簡潔性與可讀性。 Go 擁有一套小而一致的特性集。轉換後的 COBOL 邏輯保持可讀，新團隊成員能夠快速上手，從而降低長期維護風險。

單一二進位部署。 Go 編譯為一個無需安裝執行階段的自包含可執行檔。對於從大型主機遷移至 Linux 伺服器或容器的團隊，部署變得輕而易舉。

內建並行。 goroutine 與通道使得並行化主導 COBOL 系統的循序、逐筆記錄批次處理變得簡單。曾在大型主機上串列執行的夜間批次作業，通常可以重構為並行處理各個分割區。

快速編譯與雲端原生契合。 Go 的快速建置與小型容器映像檔契合現代 CI/CD 以及在 Azure、AWS 或 GCP 上的雲端部署。

您必須盡早做出的十進位精度決策

這是 COBOL 遷移至 Go 中最重要的規劃要點。COBOL 的 PIC 9 與 COMP-3 欄位保存精確的十進位（以 10 為基數）數值，這正是金融系統所倚賴的。Go 沒有原生十進位型別。十進位欄位的預設對應是 float64，它使用 IEEE 754 二進位浮點，可能在貨幣運算中引入捨入誤差。

對於任何金融或對十進位敏感的邏輯，正確的做法是使用一個十進位套件，例如以 shopspring/decimal 取代 float64。優秀的轉換器會將這項決策顯性化，而非悄然處理：Mecanik COBOL 遷移至 Go 工具 預設將十進位欄位對應為 float64，但會在其 Migration Report 中標記每一個欄位，讓您可以逐欄位決定何處需要精確的十進位運算。切勿在未經該審查的情況下將基於 float64 的金額程式碼上線。若在不引入任何額外函式庫的前提下追求精確十進位精度是優先事項，那麼 C# （原生 decimal）或 Java （BigDecimal）可能更為合適。

需要真正翻譯的 COBOL 結構

安全的遷移是將 COBOL 的語意翻譯為符合慣例的 Go，而非文字：

• 群組項（01-49 層級結構） 變為帶有匯出的 PascalCase 欄位的 Go struct 型別（ACCOUNT-BALANCE 變為 AccountBalance）。
• PIC 子句 對應到正確的 Go 型別：字母數字用 string，數值依位數用 int16 / int32 / int64，十進位欄位用 float64（或一個十進位套件）。
• PERFORM 範圍 變為函式呼叫；段落與節分解為函式。
• EVALUATE / WHEN 對應為 switch 陳述式。
• COPY 與 REPLACE（複製簿）必須被解析，包括巢狀的複製簿。
• EXEC SQL（DB2）、EXEC CICS 與 VSAM 需要重新設計至 Go 的 database/sql、sqlx 或諸如 GORM 之類的 ORM，以及現代服務模式之上。
• EBCDIC 編碼與定寬版面 需要明確轉換為 Unicode 與帶型別的模型，通常使用帶緩衝的（bufio）I/O。

遷移方法

主要有三種方法，每種都有不同的風險與成本特徵。

1. 自動轉換

工具剖析 COBOL 並產生帶有套件結構、帶型別的結構、定長整數與帶緩衝檔案 I/O 的 Go。它能迅速消除機械性工作，但不會替您做出架構決策。

最適合： 優先目標是快速消除 COBOL 相依性的大型程式碼庫。

風險： 十進位欄位、內嵌 SQL、CICS 互動與動態呼叫都需要人工審查。Migration Report 存在的意義正是揭示這些內容。

2. 並行重寫

Go 系統與 COBOL 系統並行執行，兩者處理相同的輸入，輸出相互驗證，直到 Go 通過驗證且 COBOL 退役。

最適合： 不能冒連續性風險的關鍵任務系統。

風險： 並行執行兩套系統會使遷移期間的營運成本加倍，並要求嚴格的對帳。

3. 漸進式遷移（絞殺榕）

COBOL 程式被逐一替換為 Go 等價物。系統先變為混合狀態，最終成為純 Go。

最適合： 全面重寫不切實際的大型單體 COBOL 系統。

風險： 混合狀態可能持續得比計畫更久，並且要求精心的介面設計。

對於大多數英國遷移而言，絞殺榕方法結合有選擇的自動轉換，能在風險與速度之間取得最佳平衡。

英國 COBOL 遷移至 Go 的成本

成本在很大程度上取決於程式碼庫規模、複雜性與方法。英國企業專案的參考區間：

這些數字涵蓋分析、遷移、測試與上線支援。它們不包括持續的營運成本、訓練，以及常在專案中途浮現的下游整合工作。

Mecanik COBOL 遷移至 Go 服務 專注於英國企業遷移，涵蓋評估、轉換、資料存取層實作與輸出一致性測試。對於正在權衡目標語言的組織，COBOL 遷移總覽 列出了完整範圍，包括 C#、Java、Python、C++ 與 Rust。對於從 IBM z/OS 的遷移，遺留大型主機遷移服務 在程式碼遷移之外還涵蓋基礎設施退役。

關鍵風險及因應方法

十進位精度。 Go 遷移的決定性風險。審查 Migration Report 中標記的每一個對應為 float64 的欄位，並在上線前將金融欄位切換至一個十進位套件。

未記錄的業務邏輯。 數十年內嵌的業務規則卻沒有外部文件。發現與記錄是任何遷移中最耗時、風險最集中的部分。

資料存取層。 針對 DB2 的 EXEC SQL 與 VSAM 處理必須重新設計至 database/sql 或一個 ORM 之上。這往往是單項最大的工作量。

效能與並行。 Go 效能良好，其並行能力可以勝過串列的 COBOL 批次處理，但將循序邏輯重構為並行工作負載時，必須維持順序與正確性保證。

迴歸測試涵蓋率。 透過在真實（去識別化）資料上進行全面的迴歸測試來證明 Go 輸出與 COBOL 一致，並特別關注對十進位敏感的運算。在遷移開始之前建置好測試套件。

切換風險。 一份帶有回復與對帳的詳細切換計畫是必須的。

關鍵要點

• Go 適合優先考量簡潔性、單一二進位部署與並行的 COBOL 遷移。
• Go 沒有原生十進位型別；請為每一個金融欄位提前規劃 float64 與十進位函式庫之間的決策。
• 大多數英國企業專案採用絞殺榕方法並輔以有選擇的自動化。
• 最大的風險是十進位精度、未記錄的業務邏輯與資料存取層。

常見問題（FAQ）

為何在 COBOL 遷移中選擇 Go 而非 Java 或 C#？ 選擇 Go 是為了簡潔性、快速編譯、單一二進位部署，以及用於並行化批次處理工作的內建並行。當您需要更大的企業框架生態系，或需要較少人工審查的原生／函式庫十進位支援時，選擇 Java 或 C#。

Go 如何處理 COBOL 的壓縮十進位欄位？ Go 沒有原生十進位型別，因此十進位欄位預設對應為 float64，這可能在金融運算中引入捨入。優秀的轉換器會標記每一個十進位欄位，讓您可以在需要精確運算之處，以諸如 shopspring/decimal 之類的套件取代 float64。

COBOL 邏輯能否自動轉換為 Go？ 可以，借助工具即可。優秀的轉換器產生基於套件的 Go，帶有帶型別的結構、定長整數與帶緩衝的 I/O，並標記內嵌 SQL、CICS 互動、動態呼叫與十進位精度欄位以供人工處理。架構決策仍然是人類的任務。

COMP-3 與 EBCDIC 之類的 COBOL 資料格式會如何？ COMP-3 預設對應為 float64（需針對精確十進位需求進行審查）。EBCDIC 文字與定寬版面需要明確轉換為 Unicode 與帶型別的模型，並在投入生產使用前針對真實資料進行測試。

COBOL 遷移至 Go 需要多長時間？ 小型、文件完善的系統需要 三 至 九 個月。中型企業系統需時 十二 至 二十四 個月。大型大型主機專案完成全面退役可能需要 三 至 五 年。