0

私はレガシープロジェクトに取り組んでいます。現在、状況はプロジェクトを部分に分割することを要求しています。このタスクを実行するためにどのような戦略に従う必要がありますか。

説明:

レガシープロジェクト(A)は、ほぼ明確に定義されたレイヤーを備えた完全に機能するWebアプリケーションです。しかし今、私はプロジェクトをさらに強化するために拡張する必要があります。このプロジェクトの使用法は、ビルドツールとして機能します。ただし、依存関係の管理にのみ使用されます。(プロジェクトはEclipse内で戦争形式にエクスポートされました)。

新しい拡張機能では、新しいデータテーブル、新しいUI(jsp、css、js、および画像)を追加する必要があります。

アプリケーションを強化するための私の戦略はどうあるべきか。

私の提案したデザイン。

2つの新しいプロジェクトを作成する予定です

プロジェクトB:このプロジェクトでは主な強化作業が行われます。サービスレイヤー、daoレイヤー、UIレイヤーなどのすべてのレイヤーが含まれます。そして、それ自体がWebアプリケーションになります。

プロジェクトC:プロジェクトAからいくつかの一般的なモデルとサービスコードを抽出し、このプロジェクトを作成します。このプロジェクトは、両方のプロジェクトへの依存関係として追加されます。

私のこのアプローチが大丈夫なら!それなら、展開に問題があると思います。これらの2つのプロジェクトでは、別々にデプロイする必要があります(現在はtomcatが使用されています)。しかし、私はこれら2つのプロジェクトを1つの戦争として展開する必要があります。したがって、両方のプロジェクトの構成を持つようにweb.xmlエントリを変更する計画を立てる必要があります。これには、プロジェクトの複雑さが増します。

プロジェクトの私のデザインはどうあるべきですか?私の計画は良さそうですか。

4

3 に答える 3

1

あなたが概説した一般的なアプローチは非常に賢明です(共通のサービスレイヤー(プロジェクトC)を分離し、その上にAとBを構築します)。私はそれをかなり日常的なものと呼ぶでしょう。

プロジェクトAとBの間の特定の関係について混乱しています。より正確には、プロジェクトAとBを別々に展開する必要があるのに、同じ.warの一部である必要があるのはなぜですか...?

于 2010-03-20T17:59:51.020 に答える
1

私はあなたの開発を同じ「プロジェクト」とデプロイメントユニットの一部として維持します。そうでなければ、実際の要件やアーキテクチャ上の必要性がないときに分離します。

ただし、既存のコードベースに影響を与える拡張機能の変更の難しさを説明しています。この問題については、ソース管理ツールでブランチを作成し、そのブランチで拡張機能の開発を実行することをお勧めします。これにより、ライブコードベース(バグ修正などが適用されている可能性があります)に影響を与えることなく、完全に開発およびテストできます。

完全にテストしたら、ブランチをメインコードベースにマージして、完全なアプリケーションが動作することを確認してから、リリースする前に最終的な回帰テストを実行できます。

于 2010-03-21T16:47:17.857 に答える
0

プロジェクトをこぼすことを要求する要件はどれですか?

レガシーシステムが適切に構造化されている場合は、新しいコードをレガシープロジェクトに追加するだけで済みます。

分割する必要がある場合は、新しいシステムがレガシーシステムの機能と通信するために使用する「腐敗防止レイヤー」を構築できます。これにより、レガシーシステムに変更を加えることをまったく回避できます。

于 2010-03-21T10:46:56.153 に答える