社内スクリプト言語を廃止するための移行戦略

社内で多くのことに使用するスクリプト言語があります。これは、動的ラベルがシステム全体に普及しているチューリング完全言語になるための単純な評価ステートメントとして始まりました。

問題は、このために設計されたことはなく、それが表示されることです。開発環境は貧弱であり、作成されたスクリプトはテスト可能ではなく、現在でも言語の正式な定義はありません。

言語のユーザーの間で高まる感情は、それが仕事を終え、手放す時が来たと感じていますが、既存のコードベースを新しいソリューションに考案することに移行するという困難な課題に直面しています。この議論は、移行の考えに反して使用されます。

同様の状況に直面したことがありますか？もしそうなら、古いものの使用を止めて新しいものを宣伝するためにどのような戦略を使いましたか？

最後に1つ（Moronsに感謝）、これらのスクリプトの多くは文書化されておらず、まだアクティブに使用されていますが、元の目的は失われています。スクリプトは顧客サイトでもシステムをカスタマイズするために使用されるため、文字通り数千のこれらのスクリプトがあり、その大部分はソース管理またはバージョン管理メカニズムの対象ではありません。

受け入れられた答え。

これは難しい選択です。モロンとオリバーのハイブリッドのいくらかが最良であると私は思うが、すべての答えは良いと健全なアドバイスでした。

私は結局オリバーズを受け入れることになりました。なぜなら、それがより高く受け入れられる最も良いチャンスである（ha！政治！）古いスクリプト環境を、新しい環境に統合できる呼び出し可能なステートメントにパッケージ化すると、迅速で簡単なアップグレードパスが得られます。

完了したら、警告を表示したり、古いスクリプトの編集や作成を禁止したりして、新しいスクリプトの作成を制御し、新しい言語に強制的に移行させることができます。

入力ありがとうございます！

別のアプローチは、スクリプトランタイムを選択した新しいスクリプト言語に移植し、新しい言語でレガシースクリプトを実行する方法を提供することです。

LegacyRuntime.execute（String script）;

古いコードと新しいコードを混在させることができると、移行が容易になります。

カスタムスクリプト言語を扱っているという事実は関係ありません。スクリプトのセットをある言語から別の言語に移行します。

2つの基本的な戦略があります。

1）すべてのスクリプトを（プロジェクトとして）事前に変換するために多大な労力を費やす

2）特定のスクリプトに変更を加える必要があるので、新しい言語で書き直します。しばらくして、元の言語のスクリプトがほとんど残っていない場合は、プロジェクトに取り掛かってスクリプトを完成させます。*

どちらの方法でも、厳格な規則を設定する必要があります。新しいコードはレガシー言語で書かれていません。

*全体を書き直す前に、編集をどの程度許可するかについてルールを設定することもできますが、これはループホールとして悪用される可能性があります。

私はそのような経験をしました。

私のアプローチは、言語実装をリバースエンジニアリングして、その構文とセマンティクスの多かれ少なかれ正式な仕様を導出することでした（Fortran77の手書きパーサーから数千 のキーワードを使用してBNFを分解することを想像してください）。次に、この言語用のコンパイラーを実装し、それを慣用的なLuaコードに変換します（ほとんどのコメントを保持しています）。

人気のある適切なスクリプト言語を選択するか、独自の優れた設計のDSLを実装できます。コンパイラーは、透過的な変換レイヤー（レガシースクリプトをそのまま維持する）として使用したり、スクリプトを書き直してメンテナンスを強化したりできます。