撰稿 | 千山

審校 | 云昭

在編程語言中，COBOL 絕對算得上是“上古神獸”，可以追溯到1959年左右，目前全球仍有眾多大型企業(yè)或政府機構(gòu)用的是COBOL 編寫的舊軟件。但因為太過古舊，很多新手開發(fā)者甚至聞所未聞。

為了解決COBOL應(yīng)用程序現(xiàn)代化的問題，IBM最近推出了IBM Z 服務(wù)，意在利用 AI 技術(shù)將COBOL 代碼轉(zhuǎn)譯成 Java 語言。

1、骨灰級語言迎來新生機

COBOL這門語言雖然古老，但生命力驚人。根據(jù)2022年的一項調(diào)查，生產(chǎn)系統(tǒng)中使用的COBOL代碼超過了8000億行。但問題在于，COBOL 的存在已逾一個甲子，很多編寫應(yīng)用程序的開發(fā)人員早已退休甚至離世了。

正因為“懂COBOL”的程序員極為稀缺，所以他們的薪水是相當(dāng)可觀的，甚至連美國政府都曾經(jīng)公開招募COBOL程序員，以便維護那些還在運轉(zhuǎn)中的眾多關(guān)鍵任務(wù)應(yīng)用程序。

無論從可操作性還是效率來說，COBOL在當(dāng)下都過時了，但正是由于COBOL專家的數(shù)量極少，這也導(dǎo)致“遷移”往往成為一個復(fù)雜昂貴的命題。2012年，澳大利亞聯(lián)邦銀行下決心更換了其核心COBOL平臺，這場改造耗時5年，耗資超過7億美元。

在這一背景下，IBM發(fā)布了IBM Z的Code Assistant，它使用代碼生成AI模型將COBOL代碼轉(zhuǎn)換為Java。

IBM介紹，用于 Z 大型機的 watsonx Code Assistant 旨在幫助開發(fā)人員評估和確定最需要現(xiàn)代化的代碼，使他們能夠更快地更新大型應(yīng)用程序，專注于關(guān)鍵任務(wù)。

Omdia 首席分析師 Roy Illsley對此評論道，將代碼遷移到 Java 意味著可以找到更多的程序員來做支持，如果 COBOL 應(yīng)用程序在Z大型機上的 Linux 系統(tǒng)中運行，那么它們將來可能更容易地從大型機上遷移下來(盡管這并不總是像看起來那么容易）。

據(jù)悉，IBM Z的Code Assistant將于今年第四季度上市，在此之前，IBM 會在今年9月初于拉斯維加斯舉行的TechXchange會議上演示該功能。

2、轉(zhuǎn)換成Java，代碼高度自然

那么IBM Z服務(wù)到底是如何發(fā)揮作用的呢？

IBM研究院首席科學(xué)家Ruchir Puri在接受外媒采訪時表示：“IBM建立了一個新的、最先進的生成人工智能代碼模型，將遺留的COBOL程序轉(zhuǎn)換為企業(yè)Java，生成的代碼具有高度的自然性。”

為幫助企業(yè)重構(gòu)其大型機應(yīng)用程序，IBM Z的Code Assistant可以在本地配置中運行，也可以作為托管服務(wù)在云中運行，由代碼生成模型CodeNet提供支持。

Puri提到，CodeNet 模型使用1.5萬億個參數(shù)進行訓(xùn)練，擁有 200 億個參數(shù)，設(shè)計了一個大的上下文窗口(32,000個令牌)，以“捕獲更廣泛的上下文”，實現(xiàn)“更有效的COBOL到Java轉(zhuǎn)換”。

放眼當(dāng)前市場，將COBOL應(yīng)用程序轉(zhuǎn)換為Java語法的自動化工具并不少見。Puri也承認這一點。他進一步指出，Code Assistant采取措施避免犧牲COBOL的功能，同時降低成本并生成易于維護的代碼，這就區(qū)別于市場上的一些同類競品。

因為有些類似的產(chǎn)品主要是針對COBOL 代碼進行靜態(tài)和動態(tài)分析而不是運用AI，究其根本，它們只是將代碼拆分為仍然基于 COBOL 的微服務(wù)。

watsonx Code Assistant for Z 生成的 Java 代碼將是面向?qū)ο蟮模詴c IBM 聲稱的 COBOL 應(yīng)用程序的其余部分以及 CICS、IMS、DB2 和其他 z/OS 運行時等關(guān)鍵服務(wù)進行互操作。

“IBM為IBM Z構(gòu)建了代碼助手，以便能夠混合和匹配COBOL和Java服務(wù)，”Puri說。“如果系統(tǒng)的‘理解’和‘重構(gòu)’功能建議應(yīng)用程序的給定子服務(wù)需要保留在COBOL中，那么它將保持這種方式，而其他子服務(wù)將轉(zhuǎn)換為Java。”

但這并不是等于說IBM Z的服務(wù)是完美無瑕的。斯坦福大學(xué)最近的一項研究發(fā)現(xiàn)，使用類似于它的代碼生成人工智能系統(tǒng)的軟件工程師更有可能在他們開發(fā)的應(yīng)用程序中造成漏洞。實際上，Puri警告不要在由人類專家審閱代碼之前部署由Code Assistant生成的代碼。

3、轉(zhuǎn)換成Java的影響：風(fēng)險與垃圾代碼

“像任何人工智能系統(tǒng)一樣，企業(yè)的COBOL應(yīng)用程序可能有獨特的使用模式，而IBM Z的Code Assistant可能還沒有掌握這些模式。”“必須用最先進的漏洞掃描儀掃描代碼，以確保代碼的安全性。”Puri如是說道。

事實上，也有開發(fā)人員對AI生成的代碼的不可控性提出了質(zhì)疑。在Reddit論壇的相關(guān)討論中，有網(wǎng)友指出：“在某些時候，我們無法知道人工智能的下一個動作，到底是處于天才還是愚蠢的決策。”

“有些東西我們可以理解和單元測試，但在更大的規(guī)模上，系統(tǒng)非常復(fù)雜，有很多細微差別和級別，以至于沒有一個人知道每個設(shè)計決策的‘原因’。”

還有人直接提出，“Java真的是這里最好的選擇嗎？”對此，有人表示理解，認為選擇Java是個務(wù)實的決定。“Java是選項，因為IBM大型機有一個JVM。因此，從通過 CICS 運行 COBOL 過渡到運行 Java 是相當(dāng)無縫的。特別是使用 IBM 的 Rational Developer 工具集。”

但也有人提出異議。“最大的問題是Java和COBOL的結(jié)構(gòu)完全不同，因此機械翻譯往往會產(chǎn)生完全的垃圾。認為它是一個好的候選者的唯一原因是因為你也沒有實際編程的經(jīng)驗。所以……很大程度上是一個管理決策。”

不過，開發(fā)者們多數(shù)還是認為，Java擁有強大的企業(yè)影響力，并且已經(jīng)在遺留環(huán)境中采用多年，所以考慮用它進行遷移并不令人驚訝。

IBM對這類爭論應(yīng)該也有所預(yù)料，因此該公司也表示watsonx Code Assistant產(chǎn)品組合將在未來擴展到其他編程語言。

4、COBOL二度出圈，不遠了

撇開風(fēng)險不談，在IBM看來，像Code Assistant這樣的工具對其未來的發(fā)展至關(guān)重要。今天，大約84%的IBM大型機客戶運行COBOL——主要是政府部門和金融業(yè)的客戶。雖然IBM的大型機部門仍然是其整體業(yè)務(wù)的很大一部分，但該公司將大型機視為通往廣闊的、有利可圖的混合計算環(huán)境的橋梁。

尤其再這樣一個代碼生成AI工具的時代，許多類Copilot的工具已經(jīng)問世。早前，GitHub Copilot和亞馬遜CodeWhisperer等工具的出現(xiàn)打響了競逐的號角。藍色巨人當(dāng)然不能示弱。今年5月，IBM在其Watsonx人工智能服務(wù)中推出了fm.model.code，該服務(wù)為沃森代碼助手提供支持，允許開發(fā)人員在程序(包括紅帽的Ansible Lightspeed)中使用簡單的英語提示生成代碼。

如今IBM Z服務(wù)的推出，顯而易見是在AI編碼助手領(lǐng)域針對Z大型機的針對性優(yōu)化。可以想象通過這樣的方式，COBOL的應(yīng)用前景會更加的擴大，Java技術(shù)棧的開發(fā)者也許再也不用看見這個晦澀的老語種避而遠之了。

同時，未來IBM是否將加速產(chǎn)品上市時間并繼續(xù)擴大技能庫，相信不久就會有答案。

參考鏈接：

https://techcrunch.com/2023/08/22/ibm-taps-ai-to-translate-cobol-code-to-java/

https://www.theregister.com/2023/08/22/ibm_says_genai_can_convert/

https://www.reddit.com/r/programming/comments/15z7j1u/ibm_taps_ai_to_translate_cobol_code_to_java/