既存の乱雑な Web アプリをエレガントな MVC に移行する最善の方法は何でしょうか?[閉まっている]

Question

1ヶ月ほど前に新しい会社に入社しました。会社の規模はかなり小さく、「スタートアップ」感がかなり強いです。私は他の 3 人のチームで Java 開発者として働いています。同社は主に企業/業種の人々が相互にコミュニケーションするために使用するサービスを販売しています。

私がこれまで取り組んできた、そしてこれから取り組む主な仕事の 1 つは、会社のメイン Web サイトです。そこからサービスが販売され、既存のユーザーはログインしてサービスを確認し、料金を支払い、新規ユーザーはトライアルにサインアップできます。 、など。現在、これは Tomcat 上にデプロイされた JSP アプリケーションであり、データベースへのアクセスは会社自体によって作成された永続化レイヤーを通じて行われます。

私がここで何度も繰り返し感じているフラストレーションは、大きなデザインやデザインが欠けていることです (全体的に仕事にはかなり満足しているので、これは「ああ、自分の仕事が気に入らない」というタイプの投稿ではありません)。この Web アプリケーションのアーキテクチャ。このアプリは数十の JSP ページで構成されており、サーブレットや Bean、その他の種類のフレームワークにはロジックがほとんど存在しません。JSP ページの多くは数千行のコードで構成されています。 jsp:include 他の JSP ページ、ビジネス ロジックが HTML に混在している、頻繁に使用されるコードのスニペット (Web サービス接続の取得など) が再利用されずにカット アンド ペーストされている、などです。言い換えれば、アプリケーションは混乱しています。

社内では、MVC によりよく適合するようにこのサイトを再構築しようとするうわさがいくつかありました。開発者や上層部は、このスパゲッティ コードの現在のパターンは持続可能ではなく、ユーザー向けに機能を追加するのに簡単に拡張できないことに気づき始めていると思います。上層部や開発者は完全に書き直すことに慎重ですが (既存の機能を書き直すには数週間から数か月の作業が必要になるため、十分な理由があります)、私たちは (ゆっくりと) 書き直すことについていくつかの議論を行ってきました。サイトの特定の領域を新しいフレームワークに書き込む。

アプリケーションとコードベースをこの方向に移行できるようにするための最良の戦略は何ですか?開発者として、どうすれば、入社してきてみんなに自分の書いたものがくだらないことを言うような気難しい新入社員のように思われずに、これを迅速に進めることができるでしょうか?この種の事態に遭遇したときに、あなた自身の仕事の経験で使用した実証済みの戦略や経験はありますか?

Answer 1

おそらく最善の策は、作業を進めながらゆっくりとリファクタリングすることです。これほど多くのビジネス ルールが埋め込まれたものを完全にゼロから始めるのに必要なリソースを持っている人はほとんどいません。管理者は、置き換えたアプリよりもバグが多いアプリの開発に何ヶ月も費やすことを本当に嫌います。

個別のアプリを最初から構築する機会がある場合は、そのベスト プラクティスをすべて使用し、それがどれほど効果的であるかを実証してください。可能であれば、それらのアイデアを古いアプリケーションに徐々に組み込んでください。

Answer 2

まずはマイケル・フェザーの『Working』を手に取ってください。 レガシーコードを効果的に使用する. 。次に、既存のコードをテストする最適な方法を特定します。最悪のケースは、いくつかの高レベルの回帰テストだけで行き詰まっている (またはまったく何もない) ことですが、運が良ければ単体テストがあるでしょう。次に、うまくいけば新しいビジネス機能を同時に追加しながら、ゆっくりと着実なリファクタリングを行うケースになります。

Answer 3

私の経験では、アプリの「エレガントさ」は通常、何よりもデータベースの設計と関係があります。持っている場合は、 素晴らしい 明確に定義されたストアド プロシージャ インターフェイスを含むデータベース設計により、使用するプラットフォームに関係なく、優れたアプリケーション コードが従う傾向があります。あなたが持っている場合 貧しい データベース設計では、どのプラットフォームを使用していても、常にデータベースを補うことになるため、エレガントなアプリケーション コードを構築するのは非常に困難になります。

もちろん、間には十分なスペースがあります 素晴らしい そして 貧しい, しかし、私が言いたいのは、優れたアプリケーション コードが必要な場合は、データベースが十分なレベルに達していることを確認することから始めましょうということです。

Answer 4

すでに「機能している」ものを書き換えることに価値があることを管理者に納得させるのは難しいため、メンテナンス モードのみのアプリケーションではこれを実行するのがより困難になります。まず、作業できる新しいコードに MVC の原則を適用します。ビジネス ロジックをモデルに似たものに移動し、すべてのレイアウト/ビュー コードを 1 か所に配置します)

MVC で新しいコードの経験を積むと、既存のコードを微妙に変更して、それに合わせて変更する機会が見えてくるようになります。非常に時間がかかるプロセスかもしれませんが、この方法の利点を示すことができれば、他の人を説得し、チーム全体を参加させることができるでしょう。

Answer 5

私は、ゆっくりとしたリファクタリングのアプローチに同意します。たとえば、コピーアンドペーストしたコードを、適切な Java パラダイム (クラスなどでしょうか?) に抽出します。あるいは、既存のライブラリを使用するのがよいでしょうか?)。コードが非常にクリーンで簡潔であるにもかかわらず、全体的なアーキテクチャ戦略がまだ欠けている場合、 それから 全体的なアーキテクチャに物事をより簡単に適合させることができるようになります。

Answer 6

最善の方法は、コードを印刷して丸めて捨てることです。紙もリサイクルしないでください。

1,000 行を超える長さの JSP で書かれたアプリケーションがあるとします。おそらく、恐ろしいドメイン モデル (もしあったとしても) を備えており、プレゼンテーションとビジネス ロジックを単に混ぜ合わせるだけでなく、それをブレンドし、そこに座って何時間もかき混ぜ続けます。くだらないコードを削除して MVC コントローラー クラスに移動し、正しい動作を続ける方法はありません。貧血なドメイン モデルを備えた MVC アプリや、データベース呼び出しなどを備えた MVC アプリが完成するだけです。コントローラーコードでは、まだ失敗しています。

正しい動作をする新しいアプリを試してから、2 つのアプリが相互に通信できるようにすることもできますが、それ自体が新たな複雑さになります。また、ゼロから始めた場合と同じ量の作業を行うことになる可能性がありますが、これがより良いアプローチであると上司を説得するのが簡単になる可能性があります。

Answer 7

繰り返しリファクタリングします。また、新しいフレームワークの価値を示す方法として、新しいフレームワークで完全に実行できる新機能も探してください。

Answer 8

私の提案は、他の JSP のインポートを必要としない、またはインポートがほとんどないまれなページを見つけることです。インポートされた各 JSP をブラック ボックスとして扱い、それらを中心にこれらのページをリファクタリングします (続行する前に、各変更を繰り返しテストし、動作することを確認します)。これらがクリーンアップされたら、最終的にインポートをリファクタリングするまで、インポートがさらに多く含まれるページを検索し続けることができます。

リファクタリングするときは、ページに与えられていないリソースにアクセスしようとしている部分に注目し、これをコントローラーに取り出そうとします。たとえば、データベースにアクセスするものはすべてコントローラー内に置く必要があり、コントローラーから転送経由で渡される情報の表示を JSP に処理させます。このようにして、ページごとに複数のサーブレット、またはサーブレットのようなものを開発します。このリファクタリングにはフロントコントローラーベースのフレームワークを使用することをお勧めします (個人的な経験から、Spring とそのコントローラーインターフェイスをお勧めします)。これにより、各コントローラーは個別のサーブレットではなく、適切にマップされた単一のサーブレットから委任されます。

コントローラーの場合、データベース ヒットを少しずつ試みるよりも、一度に実行する方が良いでしょう。ユーザーはページの読み込みを許容できますし、通常は許容していますが、レンダリング コードがハングして別のページを読み取ろうとしている間にクライアントにデータを与えないよりも、すべてのデータベース データがレンダリング コードに与えられた方が、ページ出力ははるかに高速になります。データベースからのデータの一部。

私はあなたの痛みを感じます、そしてこの努力が成功することを祈っています。さて、Spring Webflow を悪用するアプリケーションを保守する必要がある場合は、また別の話になります:)