大規模プロジェクト向けの Java の開発と保守に関するアドバイス

あなたが Java 開発者で、2000 のクラスと多くのフレームワークを使用するプロジェクトを開発および保守しているとします。このコードをどう理解しますか?典型的な Java エンタープライズ プロジェクト チームでは、あなたをサポートしてくれる上級エンジニアのほとんどが忙しそうです。ドキュメントも乏しいです。できるだけ早く結果を出し、プロジェクト チームに自分の能力を証明する必要があります。この状況にどう対処しますか?この記事では、新しいプロジェクトを開始する Java 開発者向けにいくつかのアドバイスを提供します。

1. プロジェクト全体を一度に理解しようとしないでください

よく考えてください、なぜプロジェクトのコードを理解することが最優先なのでしょうか？ほとんどの場合、バグを修正するか、システムの既存の機能を強化するように求められます。まず最初にやらなければならないことは、プロジェクト全体のアーキテクチャを理解することではありません。これ (プロジェクト アーキテクチャ全体を理解すること) は、プロジェクトを維持するときに大きなストレスを引き起こす可能性があります。

10 年の確かなプログラミング経験を持つ Java 開発者でさえ、たとえ 1 年以上プロジェクトに取り組んでいたとしても、プロジェクトの中核的な仕組みを理解していない可能性があります (オリジナルの開発者ではないと仮定します)。たとえば、認証メカニズムやトランザクション管理メカニズムなどです。

どうやってやったの？彼らは自分の責任分野をよく理解しており、チームに価値を提供することができます。毎日価値を提供することは、将来得られるかどうかわからない何かを知ることよりもはるかに重要です。

2. できるだけ早く価値を提供することに集中する

それでは、プロジェクトのアーキテクチャを理解するというあなたの熱意を私は否定したことになるでしょうか？絶対違う。私が求めるのは、プロジェクトを開始して開発環境をセットアップしたら、その規模の大小に関わらず、何かを提供するのに 1 ～ 2 週間もかからないように、できるだけ早く価値を提供することです。あなたが経験豊富なプログラマーで、2 週間何も成果を上げなかった場合、マネージャーはあなたが実際に仕事をしているのか、ニュースを見ているのかをどうやって知るのでしょうか?

だから配信はみんなをリラックスさせることができるんです。価値のある成果物を作成する前に、プロジェクト全体を理解する必要があると考えないでください。これは完全に間違いです。 JavaScript 検証コードを追加することはビジネスにとって非常に価値があり、マネージャーはあなたの提供を通じてあなたに対する信頼を得ることができます。これにより、あなたの貢献と従業員の価値を上司に証明できます。

毎日、バグ修正や機能強化を続けると、プロジェクトの構造が少しずつ理解できるようになります。システムのあらゆる側面を理解するのにかかる時間を過小評価しないでください。認証メカニズムを理解するには 3 ～ 4 日、トランザクション管理については 2 ～ 3 日を費やします。これらはすべて、同様のプロジェクトでの過去の経験に依存していますが、重要なのは、時間をかけてそれらを完全に理解することです。毎日の仕事の中で時間を確保し、上司に具体的な時間を尋ねないでください。

プロジェクトに継続的に保守されている単体テスト ケースがあるかどうかを確認してください。効果的な単体テスト ケースは、大規模プロジェクトのコードを理解するための優れた方法です。単体テストは、ユニットの外部インターフェイス (ユニットがどのように呼び出され、何を返すか) やその内部実装 (実際のユースケース全体をデバッグするよりも単体テストのデバッグの方がはるかに簡単です) などのコードの断片を理解するのに役立ちます。

一部の内容をよく理解できたら、メモを書くか、クラス図、シーケンス図、データ モデル図を描いて、自分や他の開発者が将来それらを保守できるようにします。

3. 大規模プロジェクトを維持するために必要なスキル

現在の仕事に携わることができるなら、すでに優れた Java テクノロジーを持っているはずです。新しいプロジェクトで良いパフォーマンスを発揮できるようにする他のスキルについて話しましょう。ほとんどの場合、プロジェクト内のタスクはバグを修正し、機能を強化することになります。

大規模プロジェクトのコードを保守するのに役立つ非常に重要なスキルが 2 つあります。

3.1 必要なクラスを素早く発見できる

バグの修正であれ、機能の拡張であれ、あらゆるメンテナンス作業において、最初のアクションは、現在修正または拡張されたユースケースで呼び出されるクラスを特定することです。修正または拡張が必要な​​クラス/メソッドを見つけたら、半分は完了したことになります。

3.2 変更の影響を分析できる

必要な変更や機能強化を完了した後、最も重要なことは、変更がコードの他の部分にダメージを与えていないことを確認することです。変更によってどの部分が影響を受ける可能性があるかを調べるには、Java のスキルと他のフレームワークの理解を活用する必要があります。最後に述べた状況を詳しく説明する 2 つの簡単な例を次に示します:

a) クラスAのequals()メソッドを変更すると、Aのインスタンスを保護するListのcontains()メソッドの呼び出しが影響を受けます。 Java に関する十分な知識がなければ、そのような影響を考慮することは困難です。

b) Webプロジェクトでは「ユーザーID」がセッションに保存されているものとします。新しいプログラマは、バグ修正として「ユーザー ID」に何らかの情報を追加する可能性がありますが、それが「ユーザー ID」に関連付けられたユースケースに影響を与えることを知りません。

上記 2 つのスキルを向上させると、プロジェクトについてあまり知らなくても、ほとんどのメンテナンス タスクがはるかに簡単になります。バグを修正する場合は、バグを見つけて修正し、変更によってプロジェクトの他の部分が損なわれないようにします。機能を強化または追加する場合、基本的には既存の機能をコピーし、同様のデザインを使用するだけです。

オンライン バンキング プロジェクトでは、なぜ「アカウント概要の表示」と「取引履歴の表示」のデザインがこれほど異なる必要があるのでしょうか? 「アカウント概要の表示」の設計を理解していれば、「取引履歴の表示」機能を完全に模倣して開発することができます。

バグの修正や機能強化に関しては、2000 個のクラスすべてが何を行うのか、システムを駆動するためにコードがどのように実行されるのかを完全に理解する必要はありません。上記のスキルがあれば、コードの変更が必要な部分をすぐに特定し、優れた Java およびフレームワークのスキルを使用して修正し、変更がプロジェクトの他の部分を壊さないようにして、プロジェクトを納品することができます。プロジェクト設計のほんの一部しか知らないかもしれません。

4. ツールを使用して、必要な変更とその変更の影響を見つけます

できるだけ早く配信するというテーマを続けると、最小限の理解でできるだけ早く配信を実装するのに役立つツールを探す必要があります。可能な限りプロジェクトを。

4.1 変更が必要なツールを素早く発見する

バグを修正する場合でも、システムを拡張する場合でも、まず、変更する必要があるユースケースによって呼び出されるクラスとメソッドを見つける必要があります。ユースケースがどのように機能するかを理解するには、基本的に、静的コード分析とランタイム分析という 2 つの方法があります。

ソースコード分析統計は、すべてのコードをスキャンし、クラス間の関係を表示します。市場には多くのデバイスやツールが存在します。例: Architexa、AgileJ、UModel、Poseidon など。

すべての静的コード分析ツールの欠点は、ユースケースにおけるクラスやメソッドの実行時呼び出しを正確に表示できないことです。したがって、Java にはコールバック パターンなどの新しい機能が追加されました。たとえば、静的分析ツールは、ページ送信ボタンがクリックされたときにどのサーブレットが呼び出されたかを推測できません。

ランタイム分析ツールは、ユースケースの実行中にクラスやメソッドのステータスを表示できます。ツールには、MaintainJ、Diver、jSonde、Java Call Tracer などが含まれます。これらのツールは、ランタイム スタックの状態をキャプチャし、ユース ケースのシーケンス図とクラス図を生成できます。

シーケンス図には、実行時にユースケースによって呼び出されるすべてのメソッドが表示されます。バグを修正している場合、そのバグはこれらのメソッドのいずれかが呼び出されている可能性があります。

既存の機能を拡張する場合は、シーケンス図を使用して呼び出しプロセスを理解してから変更します。新しい検証の追加、DAO の変更などが考えられます。

新しい機能を追加する場合は、類似した機能をいくつか見つけ、シーケンス図を使用して呼び出しプロセスを理解し、それから模倣して新しい機能を開発します。

ランタイム分析ツールを選択するときは注意してください。このタイプのツールでは、情報が多すぎることが大きな問題になります。無効な情報を簡単にフィルタリングし、さまざまなビューを便利に表示できるツールを選択してください。

4.2 変更が必要なコンテンツを素早く発見するためのツール

単体テストが効果的であれば、単体テストを実行して、変更が他のテストケースを破壊するかどうかを確認できます。大規模なエンタープライズ アプリケーションを効果的に保守およびカバーできる単体テストはまだ比較的少数です。この状況に対応するツールをいくつか紹介します。

使用できる手法はまだ 2 つあります。静的コード分析と実行時分析です。市場には多くの静的コード分析ツールが存在します。例: Lattix、Structure101、Coverity、nWire、IntelliJ の DSM。

変更されたクラスを指定すると、上記のツールは、そのクラスに依存するクラスのコレクションを識別できます。これらのツールではランタイム クラス間の呼び出し関係を表示できないため、開発者はこの情報に基づいて影響を与える可能性のあるユース ケースを「推測」する必要があります。

実行時の影響分析に使用できるツールは、MaintainJ を除いて、市場にはあまりありません。 MaintainJ はまず、ユースケースで呼び出されるすべてのクラスとメソッドをキャプチャします。すべてのユース ケースに関する上記の情報を取得すると、クラス変更がユース ケースに及ぼす影響を簡単に見つけることができます。 MaintainJ が効果的に動作するための前提条件は、ランタイムの依存関係を取得できるように、プロジェクトのすべてのユース ケースを最初に実行する必要があることです。

つまり、現時点では、変更の影響を迅速かつ正確に分析するためにツールから得られる支援はまだ限られています。まず必要に応じて影響分析を実行し、次に自分自身またはチームの他の上級メンバーによるレビューに基づいて変更の影響を判断します。自分の判断を再確認するには、上記のツールが必要になる場合があります。

5. 上記内容に関するアドバイス2つ

5.1 コードの品質を落とさないこと

早く納品するためには、アーキテクチャを完全に理解しているわけではありませんが、条件としてコードの品質を下げてはなりません。ここでは、高速配信のみに重点を置くことで発生する可能性のあるコード品質の問題をいくつか示します。

コードの変更には多くの依存関係が含まれるため、新しいコードを追加することのリスクは比較的低くなります。たとえば、すべて特定のメソッドを呼び出す 5 つのユースケースがあります。ユースケースを改善するには、このメソッドの実装を変更する必要があります。最も簡単な方法は、メソッドをコピーして名前を変更し、変更されたユースケースで新しいメソッドを呼び出すことです。こんなことはしないでください。コードの冗長性は間違いなく非常に有害です。メソッドをラップするか書き直すか、直接変更してから、すべてのユースケースを再テストしてみてください。通常は、立ち止まって考えてから自分で実装する方が良い方法です。

もう 1 つの例は、「プライベート」メソッドを「パブリック」に変更して、他のクラスからも呼び出せるようにすることです。不要な部分を露出させないように注意してください。より良い設計のためにリファクタリングが必要な場合は、実行する必要があります。

ほとんどのアプリケーションには、実装するための特定の構造とパターンがあります。プログラムを修正または強化するときは、このパターンから逸脱しないようにしてください。規則についてよくわからない場合は、他の上級開発者に変更内容をレビューしてもらうように依頼してください。規約に違反する実装を行う必要がある場合は、より小さなクラスに配置するようにしてください (200 行クラスのプライベート関数は、アプリケーションの全体的な設計に影響を与えるべきではありません)

5.2 プロジェクトのアーキテクチャの理解をやめないでくださいin Depth

記事に記載されている方法によると、プロジェクトについてほとんど知らない状態で納品でき、それを継続できると仮定すると、プロジェクトのアーキテクチャを深く理解できなくなる可能性があります。これは長期的にはあなたのキャリアに役立ちません。経験が増えるにつれて、より大きなモジュールのタスクを引き受ける必要があります。完全な新機能の構築やプロジェクトの基本設計の一部の変更などの大幅な改善。これらの改善ができるようになるまでに、プロジェクトの全体的なアーキテクチャについてかなりよく理解できるはずです。この記事に記載されている方法は、プロジェクト全体を完全に理解することを妨げるものではなく、可能な限り短期間で自分自身を改善できるようにするものです。

6. 結論

この記事全体は、プロジェクトの必要な理解を前提として、迅速な納品に重点を置いています。コードの品質を損なうことなくこれを行うことができます。

バグを修正する場合は、すぐに見つけて修正してください。必要に応じて、実行時分析ツールを使用できます。新しい機能を追加する場合、類似した機能を探し、プロセスを理解して (ツールが必要です)、書くことができます。

これは簡単に聞こえるかもしれませんが、実用的でしょうか?確かに。ただし、前提として、優れた Java テクノロジと、最初にコードを変更してから変更の影響を分析するためのフレームワークについての十分な理解があることが必要です。変更の影響を分析するには、変更を実装するよりも多くのスキルが必要です。変更の影響を分析する際には、上級開発者の支援が必要な場合があります。

IT 運用予算の約 50% が、単純なバグ修正と機能強化に費やされています。記事の提案によると、メンテナンス活動に資金を節約するのに非常に役立つはずです。