5

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

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

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

社内では、MVCにより適したものになるように、このサイトを再構築しようとしているといううわさがありました。開発者や上級者は、この現在のスパゲッティコードのパターンは持続可能ではないか、ユーザーに機能を追加するために非常に簡単に拡張できないことに気づき始めていると思います。上層部と開発者は、物事を完全に書き直すことを警戒しています(これは、既存の機能を書き直すのに数週間または数か月の作業を意味するため、正当な理由があります)が、(ゆっくりと)書き直すことについていくつかの議論がありました。サイトの特定の領域を新しいフレームワークに書き込みます。

アプリケーションとコードベースをこの方向に移動できるようにするための最良の戦略は何ですか?開発者として、私はどうすればこれを迅速に進めることができますか?仕事に就き、自分が書いたものはくだらないとみんなに言う、ぎくしゃくした新しい人のようには見えませんか?このようなことに遭遇したときに、自分の仕事の経験で使用した実証済みの戦略や経験はありますか?

4

8 に答える 8

12

あなたの最善の策は、おそらくあなたが進むにつれてゆっくりとそれをリファクタリングすることです。非常に多くのビジネスルールが埋め込まれているものを最初から完全に開始するために必要なリソースを持っている人はほとんどいません。交換したものよりも多くのバグがあるアプリの開発に何ヶ月も費やすと、経営陣はそれを本当に嫌います。

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

于 2008-09-02T18:43:56.647 に答える
4

まず、MichaelFeatherの「レガシーコードで効果的に機能する」のコピーを入手します。次に、既存のコードをテストするための最良の方法を特定します。最悪のケースは、いくつかの高レベルの回帰テストだけで(またはまったく何も)立ち往生していることです。運が良ければ、単体テストがあります。次に、新しいビジネス機能を同時に追加しながら、うまくいけばゆっくりと着実にリファクタリングする場合です。

于 2008-09-02T21:48:52.897 に答える
2

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

もちろん、素晴らしいもの悪いものの間には十分な余地がありますが、私のポイントは、優れたアプリケーションコードが必要な場合は、データベースが適切に機能していることを確認することから始めます。

于 2008-09-02T18:46:10.793 に答える
2

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

MVCの新しいコードの経験を積むにつれて、既存のコードを微妙に変更して、それも一致するようにする機会を見つけることができます。これは非常に遅いプロセスになる可能性がありますが、この方法の利点を示すことができれば、他の人を説得してチーム全体を参加させることができます。

于 2008-09-02T18:48:31.490 に答える
2

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

于 2008-09-02T18:50:28.427 に答える
1

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

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

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

私はあなたの痛みを感じており、この努力の幸運を祈っています。さて、Spring Webflow を悪用するアプリケーションを維持する必要がある場合、それは別の話です:)

于 2008-09-16T03:16:42.340 に答える
1

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

于 2008-09-15T18:52:48.903 に答える
0

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

1,000 行以上の JSP で記述されたアプリケーションがあります。それはおそらく恐ろしいドメインモデルを持っており(もしそれがあったとしても)、プレゼンテーションをビジネスロジックとミックスするだけでなく、それをブレンドしてそこに座って何時間も攪拌し続けます. くだらないコードを取り出して MVC コントローラー クラスに移動しても、正しいことを行う方法はありません。貧血ドメイン モデルまたはデータベース呼び出しのようなものを持つ MVC アプリになってしまうだけです。コントローラーコードでは、まだ失敗しています。

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

于 2008-09-02T19:35:12.373 に答える