コードを移植する誰かにどのようなヒントを提供できますか？

ある言語から別の言語にコードライブラリを移植したり、別のコンパイラ、環境で動作するようにコードライブラリを書き直したりしている人に対して、どのようなアドバイス（ヒント、テクニック、落とし穴など）がありますか？

すべてのプラットフォーム（言語およびシステムライブラリ）には、独自のペルソナがあります。RubyプログラマーがAPIを設計する方法は、Rubyをその独自のものにする独自の機能と文化を利用しています。これは、CまたはC ++開発者がAPIを設計する方法とは明らかに異なります。これは、JavaまたはC＃開発者が行う方法とは異なります。

元のプラットフォームからアイデアを取り、それらを新しいプラットフォームのコンセプトとなるように作り上げたいと考えています。プラットフォームの他のライブラリとはまったく異なる方法で設計されたライブラリを使用するほど、自然に感じるものはありません。実際に適切に設計されたエレガントなプログラミングプラットフォームがいくつかあります。これらの強みをポートに活用したいと考えています。

「to」と「from」の両方の言語/フレームワークのネイティブ機能を把握します。

JavaScriptからカレンダーライブラリをiOSに移植していました。iOSには堅牢なカレンダークラスがありますが、JavaScriptには私にとって役に立たないものがありました。（私は宗教暦からグレゴリオ暦に、またはその逆に変換していました。）

Objective-Cでライブラリ全体を書き換えるのに時間を費やしたのは、コードが大部分冗長であることを理解するためだけでした。（ちなみに、私は仕事がうまくいかず、不正確な結果が出ていました。そのとき、一歩下がって自分の間違いに気付きました。）

数十行の変換メソッドは、6行程度のネイティブフレームワークコードに置き換えることができました。

これが重要なプロジェクト（多くの場合、移植が重要）の場合は、コードの各部分とシステム全体を移植する前に、完全なテスト計画（理想的にはターゲット言語での単体テスト）を記述します。

移植が最初の試行で100％正確になるという世界には方法がないため、事前にすべてをキャッチしていることを確認する必要があります。

可能であれば、元のコードに対して同じ計画を実行してください。正確に記述された保証はなく、実際には同等の動作をすることは、正しくない実装に依存している可能性があるためです。

->コーディングされた方法ではなく、機能に焦点を当てます。

->一部の要素はすでに言語、プラットフォームなどで処理できるため、書く前に考えてください。

->新しいプラットフォームの利点を活用します。

「移植」-言葉を使用しているように見える-は、迷惑なレガシーコードを使用したTDDにすぎません。

テストケースを正しく取得します。レガシーコードがテストケースに合格することを確認します。

次に、レガシーコードを破棄します。

次に、テストケースに合格する新しいコードを新しい言語で記述します。

クラスダイアグラム/階層ツリーを作成して、最初に移植するものを把握します。基本的なデータ型をマップします（int-> Int32？）。データ構造についても同じことを行います。