あなたが 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 つの簡単な例は、最後に述べた状況を詳しく説明しています:
したがって、変更の影響を分析できるように、Java 言語とアプリケーションで使用するフレームワークの両方を深く理解する必要があります。
上記 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 つのユースケースがあります。ユースケースを改善するには、このメソッドの実装を変更する必要があります。最も簡単な方法は、メソッドをコピーして名前を変更し、改善された使用例で新しいメソッドを呼び出すことです。こんなことはしないでください。コードの冗長性は間違いなく非常に有害です。メソッドをラップするか書き直すか、直接変更してから、すべてのユースケースを再テストする必要があります。これは通常、立ち止まって考えてから自分で実装する良い方法です。
別の例は、「プライベート」メソッドを「パブリック」に変更して、他のクラスからも呼び出せるようにすることです。不要な部分を露出させないように注意してください。より良い設計のためにリファクタリングが必要な場合は、実行する必要があります。
ほとんどのアプリケーションには、実装のための特定の構造とパターンがあります。プログラムを修正または強化するときは、このパターンから逸脱しないようにする必要があります。プロトコルについて不明な点がある場合は、他の上級開発者に変更内容を確認してもらうように依頼してください。仕様に違反する何かを実行する必要がある場合は、それをより小さいクラスに配置するようにしてください (200 行のクラス内のプライベート関数は、アプリケーションの全体的な設計に影響を与えるべきではありません)
5. 2 プロジェクトのアーキテクチャを深く理解することをやめないでください
記事に挙げた方法では、プロジェクトについてあまり知らない状態で納品できることを前提としており、このままだとプロジェクトのアーキテクチャを深く理解できなくなる可能性があります。これは長期的にはあなたのキャリアに役立ちません。経験が増えるにつれて、より大きなモジュールのタスクを引き受けるようになります。完全な新機能の構築や、プロジェクトの基本設計の変更やその他の大きな改善などです。これらの改善を行うことができれば、プロジェクトの全体的なアーキテクチャをかなりよく理解できるはずです。この記事に記載されている方法は、可能な限り短期間で改善することのみを可能にしますが、プロジェクト全体を完全に理解することを妨げるものではありません。
6.結論
この記事全体の焦点は、プロジェクトについて必要な理解を深め、それを迅速に提供することです。コードの品質を損なうことなくこれを行うことができます。
バグを修正したい場合は、バグを見つけてすぐに修正してください。必要に応じて、実行時分析ツールを使用できます。新しい機能を追加したい場合は、同様の機能を探し、プロセスを理解して (必要に応じてツールを使用して)、作成することができます。
これは簡単に聞こえるかもしれませんが、実用的でしょうか?確かに。前提として、優れた Java スキルとフレームワークの十分な理解があり、最初にコードを変更してから変更の影響を分析できることが前提となります。変更の影響を分析するには、変更を実装するよりも多くのスキルが必要です。変更の影響を分析する際には、上級開発者の支援が必要な場合があります。
運用IT予算の約50%は、単純なバグ修正と機能強化に費やされています。この記事の提案は、メンテナンス活動の費用を節約するのに非常に役立ちます。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
