最終的に古いアプリケーションにマージされる新しいアプリケーションを設計するための方法論

Question

現在、私はC＃で新しいスタンドアローンアプリケーションを開発しているチームにいます。最終的な目標は、このスタンドアローンアプリを、同じプロセスに関連する以前に開発されたより大きなアプリケーションにロールすることです。

私は、A）より新しいコードの設計、古いコードが最もメンテナンス可能なシステムではない場合の特質、およびB）より新しいものの統合に役立つ方法論またはプロセスに関する情報を探しています。応用。

明らかにそこには何も特定のものはありません。私たちのアプリケーションは設計上独自のものであり、方法論が役に立たない詳細があります。しかし、私はトピックに関するいくつかの良い一般的な知識を得ることに興味があります。

EDIT： 提案これまでのところ、物事はすべての良い慣行が一般的であるとされ、モジュールのコンテナとして新しいコードをビルドし、古いコードをリファクタリング、ユニットテストで古いものと新しいコードをカバー私は可能な限り練習します。しかし、これらは、全体的な方法論の個々の部分であると私は思えます。

Answer 1

まず、古いアプリケーションが内部的にどのように動作するかを理解する必要があります。

新しいコードを設計するときは、階層化されたアプローチで再利用可能な小さなコンポーネントを構築するように細心の注意を払う必要があります。もちろん、それは何も特別なものではありません。良いプログラマは常にそれを試みようとしますが、特定のシナリオではより重要です。ある時点で、それをスタンドアロンアプリケーションにするためには、古いアプリケーションに既に存在する一部を複製する必要があります。ログイン画面、ワークフロー管理など。古いシステムからそれらの部品を再利用するか、新しい部品APIを主要ビジネスロジックと互換性を持たせてください。そうすれば、新しいアプリケーションを古いアプリケーションに統合する方がはるかに簡単になります。

Answer 2

これは、方法論ではなくアプリケーションアーキテクチャに関係しているので、探している答えがわかりません。

つまり、アプリケーションコンポーネントをホストする軽量コンテナとしてスタンドアローンを設計すると、後でより大きなコンテキストにコンポーネントを移行できるようになります。

Answer 3

Fowlerは古いコードをリファクタリングすることをお勧めします。少し時間がかかりますが、

）このコードを新しいコードと簡単に統合することができます。

B）あなたとあなたのチームは古いコードをよく理解します。

あなたの場合、あなたのコードを覆うことについて、また単体テストで古いコードを扱うことも考えています。