現在、私はC＃で新しいスタンドアロンアプリケーションを開発しているチームに所属しています。最終的な目標は、このスタンドアロンアプリを、同じプロセスに関連する以前に開発されたより大きなアプリケーションに組み込むことです。
私の質問はこれです：私は、A）特に古いコードが最も保守しやすいシステムではない場合に、上記の新しいコードの設計、およびB）上記の新しいアプリケーションの統合に役立つ方法論またはプロセスに関する情報を探しています。
明らかに、そこには具体的なものは何もありません。私たちのアプリケーションは設計がユニークであるため、方法論が役に立たない詳細があります。ただし、このトピックに関する一般的な知識を得ることに興味があります。
編集： これまでの提案、古いコードのリファクタリング、モジュールのコンテナーとしての新しいコードのビルド、単体テストでの新旧のコードのカバーは、すべて一般的に良い習慣であり、可能な場合は私が実践するものです。これらは全体的な方法論の個々の部分であるように私には思えます。
まず、古いアプリケーションが内部でどのように機能するかを理解する必要があります。ワークフロー、セッション、ユーザー権限などをどのように管理しますか。
新しいコードを設計するときは、階層化されたアプローチで小さくて再利用可能なコンポーネントを構築するために特別な注意を払う必要があります。もちろん、それは特別なことではありません。優れたプログラマーは常にそれを試みますが、与えられたシナリオではより重要です。ある時点で、スタンドアロンアプリケーションにするには、ログイン画面やワークフロー管理など、古いアプリケーションにすでに存在するいくつかの部分を複製する必要があります。古いシステムからそれらの部分を再利用するか、新しいものを作成してください。パーツAPIと互換性があり、主要なビジネスロジックから分離されています。そうすることで、新しいアプリケーションを古いアプリケーションに統合するのがはるかに簡単になります。
これが方法論ではなくアプリケーションアーキテクチャに関係しているため、これがあなたが探している答えであるかどうかはわかりません。
とは言うものの、スタンドアロンをアプリケーションコンポーネントをホストする軽量コンテナとして設計すると、事実上、後でコンポーネントをより大きなコンテキストに移行できるようになります。
Fowlerは、古いコードをリファクタリングすることをお勧めします。少し時間がかかりますが：
A）このコードを新しいコードと統合する方が簡単です。
B）あなたとあなたのチームは古いコードをよりよく理解するでしょう。
あなたの場合、私はあなたのコードとおそらく古いコードを単体テストでカバーすることも考えます。