當(dāng)前位置：首頁 > 编程语言 > C# >内容正文

C#

java转换为c#_将25k行C＃转换为Java的经验教训

發(fā)布時間：2023/12/3 C# 68 豆豆

生活随笔收集整理的這篇文章主要介紹了 java转换为c#_将25k行C＃转换为Java的经验教训小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

java轉(zhuǎn)換為c#

由于各種原因，我最近完成了一個將復(fù)雜的財務(wù)應(yīng)用程序從C＃轉(zhuǎn)換為Java的項目。港口的原因大部分是非技術(shù)性的，而是對相關(guān)企業(yè)的一項戰(zhàn)略舉措。

這是一次有趣的經(jīng)歷，我在此過程中吸取了一些經(jīng)驗教訓(xùn)，可以分享這些經(jīng)驗。

1.在現(xiàn)有系統(tǒng)上構(gòu)建語言中立的測試。

我將從最重要的一課開始。移植系統(tǒng)時，由于任何原因這可能是任何端口，因此必須具有確定該端口是否成功的標(biāo)準(zhǔn)。最好的方法是圍繞原始系統(tǒng)構(gòu)建一整套測試，這些測試可以“ 無需更改即可導(dǎo)出”到新系統(tǒng)。因此，例如，如果要將系統(tǒng)從Java遷移到不支持JUnit的另一種語言，則沒有一套JUnit測試是不好的。我無法強調(diào)在沒有干預(yù)的情況下將測試的更改從字面上從舊系統(tǒng)復(fù)制到新系統(tǒng)有多么重要。

JUnit測試的另一個問題是它們通常與現(xiàn)有的實現(xiàn)緊密地聯(lián)系在一起。由于將要重寫實現(xiàn)，因此測試無法在實現(xiàn)之間移植。

我們選擇的并且非常有效的策略是使用Cucumber測試。幾乎所有語言都有Cucumber的綁定，IDE（至少是IntelliJ和Visual Studio都）很好地支持了Cucumber，此外，該測試是人類可讀的。這樣，您可以讓非技術(shù)用戶參與測試的準(zhǔn)備工作，以為端口做準(zhǔn)備。（順便說一句，我們試圖通過記錄舊系統(tǒng)所做的所有工作并圍繞這些需求構(gòu)建測試來讓用戶定義新系統(tǒng)的需求，但這不足為奇，這并不令人意外。基于構(gòu)建測試用例要好得多而不是嘗試為新系統(tǒng)發(fā)明它們！）。

使用Cucumber確實是成功的，每當(dāng)系統(tǒng)之間存在差異時，我們都會創(chuàng)建一個新的測試。到完成時，我們已經(jīng)有了大約1000種方案，我們對新系統(tǒng)的正確性充滿信心。它為我們提供了堅實的基礎(chǔ)，我們需要繼續(xù)開發(fā)新系統(tǒng)中的其他功能和重構(gòu)。

2.嘗試并使盡可能多的翻譯自動化。

當(dāng)面對超過25k行的C＃時，考慮將每行手動轉(zhuǎn)換為Java是一件非常艱巨的任務(wù)。幸運的是，那里提供了非常有用的工具。我們使用的產(chǎn)品來自有形軟件解決方案。花了幾百美元，它實際上節(jié)省了數(shù)百個工時。無論如何它都不是完美的，但是它將為您提供Java代碼的結(jié)構(gòu)（部分代碼允許將C＃中的類的代碼拆分為多個文件），并嘗試了使您可以使用的Java。

在我們的案例中，幾乎沒有任何生成的代碼可以實際編譯，但這確實是一個很好的起點。我的類比是OCR的早期嘗試。您可以掃描文檔，但是當(dāng)您在編輯器中打開文檔時，會發(fā)現(xiàn)許多未正確識別的單詞帶有紅色下劃線。這是要遍歷所有紅色底線并弄清楚單詞應(yīng)該是什么的問題。自動翻譯產(chǎn)生的代碼大同小異，當(dāng)它被導(dǎo)入IDE時，會出現(xiàn)許多編譯器錯誤。有時，自動化過程會保留在原始C＃中，并說無法自動完成翻譯。值得稱贊的是，該工具總是偏向于保守，它從未對所產(chǎn)生的Java犯錯，這一點很重要。

3.不要著急翻譯

運行自動翻譯后，您將需要返回代碼并手動修復(fù)編譯錯誤。如果我有時間，我將花費10倍以上的時間來確保對代碼所做的每一次更改都是絕對正確的。由于我不是C＃專家，所以有時我會假設(shè)C＃庫的工作方式。這些假設(shè)并不總是正確的，有時我會付出沉重的代價來調(diào)試場景，如果我在原始譯文中更加小心一點，就永遠(yuǎn)不會有問題。花時間閱讀要翻譯的類的C＃API絕對值得。我發(fā)現(xiàn)在使用Date和DateTime對象時，這一點特別重要。

花時間學(xué)習(xí)Visual Studio IDE也是值得的。并行調(diào)試時，如果您知道如何正確使用IDE，從長遠(yuǎn)來看將節(jié)省時間。

4.使用Java 8

除了使用Java 8的所有顯而易見的原因（這是Java的最新版本，所以為什么不使用它……）之外，Stream API也可以很好地映射到C＃Linq。語法略有不同，例如Java使用'->'和C＃使用'=>' ，但是使用Java 8的新功能確實有助于保持代碼的可比性，這在進(jìn)一步調(diào)試時都很有幫助。

5.注意意外行為

語言的某些功能是您不應(yīng)該依賴的，但可能會完全一樣。讓我舉一個我花了太多時間的例子來說明。 C＃代碼使用的是Dictionary ，代碼生成器將Dictionary正確翻譯為HashMap 。兩者都是無序地圖。但是，即使在Dictionary遍歷Dictionary時沒有按合同對Dictionary進(jìn)行排序（也存在OrderedDictionary ），它似乎仍可以保留插入順序。 HashMap并非如此，并且由于元素的順序?qū)τ诮Y(jié)果HashMap ，因此我們發(fā)現(xiàn)了難以調(diào)試的差異。解決方案是用確實保留順序的LinkedHashMap替換HashMap所有實例。

6.不要過早重構(gòu)

從代碼生成器生成的代碼不是很漂亮。實際上，要查看它幾乎是可怕的，違反了有關(guān)命名約定等的幾乎所有規(guī)則。隨著時間的流逝，它很容易整理。抵制這種誘惑，直到所有單元測試都通過為止。您以后總是可以整理一下。重構(gòu)（甚至重命名）可能會引入錯誤，尤其是在定義上您不熟悉的代碼庫中。同樣，您可能決定在某個地方重新運行代碼生成器，并且所有整理工作最好都需要合并，最壞的情況是浪費時間。

結(jié)論

即使您不太熟悉C＃，將相當(dāng)復(fù)雜的程序從C＃轉(zhuǎn)換為Java也不是沒有可能。使用正確的工具和技術(shù)，嚴(yán)格地進(jìn)行可靠和可重復(fù)的測試，將對您的項目成功產(chǎn)生重大影響。

翻譯自: https://www.javacodegeeks.com/2015/05/lessons-learnt-translating-25k-line-of-c-into-java.html