実行フローを追跡できる単一のエントリー・ポイントがないエンタープライズJavaプロジェクトで作業しています。一部のプロジェクトには数百のクラスがあり、プロジェクトに機能を追加するように求められたとき、コードのどこから始めればよいか迷うことがよくあります。
時間を無駄にすることなく機能をすばやく実装できるように、そのようなプロジェクトに飛び込むための最良の方法は何ですか。
実行フローを追跡できる単一のエントリー・ポイントがないエンタープライズJavaプロジェクトで作業しています。一部のプロジェクトには数百のクラスがあり、プロジェクトに機能を追加するように求められたとき、コードのどこから始めればよいか迷うことがよくあります。
時間を無駄にすることなく機能をすばやく実装できるように、そのようなプロジェクトに飛び込むための最良の方法は何ですか。
回答:
プロジェクトには、よくメンテナンスされた単体テストのスイートがありますか?ユニットテストは、コードが何をするかについてのプログラム的なドキュメントです。
さらに、新しい機能のコードを挿入する必要がある場所を特定し、多かれ少なかれ残りを無視するために、アプリケーションのアーキテクチャについて十分に学ぶ必要があります。これを行うためにコードベース全体を知る必要はありません。プロジェクトが適切に設計されている場合、機能はすでに十分にカプセル化および分離されているため、関連する部分に集中できます。運が良ければ、プロジェクトは既によく知られているアーキテクチャーに準拠しており、これはユーザーが従うためのマップとして機能します。
コードには常に1つ以上のエントリポイントがあります。MVCプロジェクトの場合、エントリポイントはURLに基づくコントローラーメソッドです。このメソッドはほぼ確実にデータリポジトリにアクセスし、ビューを返します。そこから始めましょう。
中間層(ビジネスロジックレイヤー)から始めます。
それが非UIベースのアプリケーションである場合、それはコントロールがユーザーアクションまたはトリガーイベントのために来る場所の1つです。デバッグモードの場合は、上と下(おそらくデータアクセス層)までトレースできます。
しばらく時間がかかりますが、これは文書化されていないプロジェクトに飛び込む効率的な方法です。
プロジェクトがフレームワーク(struts-config.xml、ejb config xmls、spring config xmls)を使用している場合、定義されたインターフェースがあり、そこから開始することもできます。
常にエントリポイントがあります。Javaエンタープライズアプリの場合:サーブレット、フィルター、およびコンテキストリスナーが一番上にあり、通常はスプリングコンテキストローダーなどのアプリケーションブートストラップにつながり、コントローラー、コントローラー、エンティティ、ビューにつながります。特に、春、タペストリー、改札などのフレームワークが使用されている場合は、実際には非常に簡単です。フレームワークがリクエストをどのように処理するかがわかったら、必要な拡張ポイントを特定できるはずです。
まず、クラス階層から始めます。すばらしいものがある場合は、そうでない場合でも、コードをリバースエンジニアリングして作成できるツールを見つけてください。それから、物事がどのように関連しているかを見ることができます。物事がどのように関連しているのかがわかると、クラスの大きな「手詰まり」を作る代わりに、少なくともエリアをターゲットにすることができます。それらが互いにどのように関連付けられているかを確認できる領域をターゲットにすることができます(このクラスはこのクラスの関連付けですか、このクラスのセットはデザインパターンなどです)。あなたが見ているものの周りにいくつかの順序と構造を追加してから、各セクションを分解してみてください。
編集:
スタックオーバーフローからの投稿で、Eclipseで(またはスタンドアロンアプリケーションとして)リバースエンジニアリングしてモデルを生成するために使用できるツールの概要を以下に示します。
「象はどうやって食べるの?」「一度に一口」。
エントリポイントがなく、何が行われたか、およびその理由が明確に文書化されていない場合、Javaプロジェクトを拡張することはほとんど不可能です。
参考までに、プロジェクトをお客様に提供するとき、Java docと印刷されたドキュメントだけでなく、UMLモデルに体系的に参加するようになりました。クラス図として表示されたモデルから何百ものビューを作成します。たくさんのコメントを追加し、静的アーキテクチャ、ビジネスルール、メソッドフローについて説明します。お客様が彼のコードを取得して別の会社に提供したい場合は、展開レベルだけでなくアーキテクチャレベルでも既存のソフトウェアを簡単に変更できます。単一のモデルからの動的UMLビューの強力でシンプルで見事な使用法。
とは言っても、この情報をすべて提供することに関心のあるインテグレーターはほとんどいません。いったん顧客が閉じ込められたら、彼を手放さない方が良いからです。完全なモデルと動的UMLナビゲーションを提供することで、顧客は独立することができるため、これはビジネスの収益に適していません。なぜ大手銀行や通信会社がインテグレーターにとらわれてプロジェクトのデリバリー時に完全なモデルを求めないのかについて、私はまだ理解していませんか?Javaコードまたは印刷されたドキュメントでは不十分です。印刷されたドキュメントは通常、自動プロセスです。コードから情報を抽出して印刷したり、PDFを提供したりすることには、真の価値はありません。
常にエントリポイントがあり、それらを見つける必要があります。スケジュール駆動型のバッチアプリケーションの場合、どこかにタスクが構成されています。Webアプリケーション(Springを使用)の場合は、マッピングとコントローラーがあります。Webサービスアプリケーションの場合は、サービスエンドポイントがあります。Swingアプリケーションの場合は、イベントハンドラーなどがあります。そして、それが大きなolのコマンドラインアプリケーションである場合は、main()
メソッドがあります。
「すぐに飛び込む」ことについては、まあ、エントリーポイントを見つけるのにどれだけ時間がかかるかは、本当に個人的なものです。システムが確立されたパターンに従って記述されており、フレームワークと基になるビジネスルールおよびプロセスに精通している場合は、それらを非常に迅速に理解できるはずです。そうでない場合は、さらに時間がかかることがあります。しかし、普遍的な「トリック」はありません。経験を蓄積し、パターンを認識する方法を学び、フレームワークがどのように構築および編成されているかを理解し、改善します。
レガシーコードの扱いについて:
実行の流れについて:
エントリーポイントについて: