Javaで書かれたアプリケーションがあります。Inはいくつかのファイルに保存されます。さまざまなメソッドでさまざまなクラスを使用します。コードは大きくて複雑です。コードのグラフィカルモデル（ある種の有向グラフ）があれば、コードを理解しやすくなると思います。コードを視覚化するための標準的な方法はありますか？私はUMLの使用法を考えています（それが正しい選択かどうかはわかりません）。誰かが私に何かをお勧めできますか？
追加した：
私は2つの可能性を考えます：
追加2：
無料で何かを持っているといいでしょう。
いくつかのUMLツールを使用してみましたが、ほとんどのUMLツールのリバースエンジニアリング機能はコードの理解に役立たないことがわかりました。彼らはニーズの設計に焦点を合わせており、リバースエンジニアリング機能は多くの場合、多くの役に立たない情報の巨大な写真を表示することになります。Microsoft Officeコードベースで作業していたとき、一般的なデザイン/モデリングツールよりもペンと紙を使用する方が便利であることがわかりました。
通常、これをさまざまな方法で行うことを検討します。
そこに着いたら、プロジェクトを理解しようとするときは、次の点に注意してください。
注：私はArchitexaの創設者です。Javaコードを理解して文書化するのに役立つツールを作成していますが、上記では偏見を持たないようにしています。私の意図は、これが私の博士号の一部として焦点を合わせたものであることを前提として、ツールとオプションを提案することです。
あなたが使うべき最も重要なツールはあなたの脳であり、それは無料です。
あらゆる種類の標準的な視覚化方法を使用する必要がある理由はなく、好きなメディアを使用できます。紙、ホワイトボード、フォトショップ、Visio、パワーポイント、メモ帳：これらすべてが効果的です。クラス、オブジェクト、メソッド、プロパティ、変数の図を描きます-アプリケーションを理解するために見るのに役立つと思うものは何でも。聴衆はあなたのチームの他のメンバーだけでなく、あなた自身でもあります。見て、すぐに理解するのに役立つ図を作成します。それらをワークスペースの周りに投稿し、定期的に見て、システムアーキテクチャ全体を構築するときに思い出させてください。
UMLおよびその他のコード文書化標準は、実行できる図の種類と、含めることを検討する必要のある情報に関する優れたガイドラインです。ただし、ほとんどのアプリケーションではやり過ぎであり、基本的に、標準なしで文書化することに個人的な責任を負わない人々のために存在します。UMLに従って手紙を書くと、アプリケーションを作成する代わりに、ドキュメントに多くの時間を費やすことになります。
それはいくつかのファイルに保存されます。さまざまなメソッドでさまざまなクラスを使用します。コードは大きくて複雑です。
学校の外で書かれたすべてのJavaコードは、特にプロジェクトを開始する新しい開発者にとっては、そのようなものです。
これは古い質問ですが、これはGoogle検索で取り上げられているので、将来の訪問者に役立つように、ここに回答を追加します。また、私がMaintainJの作者であることを開示させてください。
アプリケーション全体を理解しようとしないでください
これを聞いてみましょう-なぜコードを理解したいのですか？ほとんどの場合、バグを修正しているか、アプリケーションの機能を強化しています。最初にやるべきではないことは、アプリケーション全体を理解することです。プロジェクトを新たに開始するときにアーキテクチャ全体を理解しようとすると、圧倒されます。
私がこれを言うとき、私を信じてください-10年以上の確かなコーディング経験を持つ開発者は、同じプロジェクトに1年以上取り組んだ後でも、アプリケーションの特定の部分がどのように機能するかを理解できない可能性があります（元の開発者ではないと仮定します）。彼らは、認証がどのように機能するか、またはアプリケーションでトランザクション管理がどのように機能するかを理解していない可能性があります。私は、1000から2000のクラスを持ち、さまざまなフレームワークを使用する典型的なエンタープライズアプリケーションについて話しています。
大規模なアプリケーションを維持するために必要な2つの重要なスキル
それでは、彼らはどのように生き残り、大金を支払われるのでしょうか？経験豊富な開発者は通常、自分が何をしているかを理解しています。つまり、バグを修正する場合は、バグの場所を見つけて修正し、アプリの残りの部分を壊さないようにします。機能を拡張したり、新しい機能を追加したりする必要がある場合、ほとんどの場合、同様のことを行う既存の機能を模倣する必要があります。
これを行うのに役立つ2つの重要なスキルがあります。
彼らは、バグを修正しながら行う変更の影響を分析することができます。まず、問題を特定し、コードを変更してテストし、問題が機能することを確認します。次に、Java言語とフレームワークを「十分に」知っているので、アプリの他の部分が壊れるかどうかを判断できます。そうでない場合は、完了です。
私は彼らが単にアプリケーションを強化するために模倣する必要があると言いました。効果的に模倣するには、Javaをよく理解し、フレームワークを「十分に」理解する必要があります。たとえば、新しいStruts Actionクラスを追加して構成xmlに追加する場合、最初に同様の機能を見つけ、その機能のフローに従って、その機能を理解しようとします。構成を少し調整する必要がある場合があります（「セッション」スコープよりも「リクエスト」にある「フォーム」データなど）。しかし、フレームワークを「十分に」知っていれば、簡単にこれを行うことができます。
つまり、バグを修正したりアプリを強化したりするために、2000のすべてのクラスが何をしているのかを理解する必要はありません。何が必要かを理解してください。
即時の価値を提供することに焦点を当てる
それで、私はあなたがアーキテクチャを理解することを思いとどまらせていますか？いいえ、まったくありません。私があなたに求めているのは、配達することだけです。プロジェクトを開始し、PCで開発環境をセットアップしたら、どんなに小さなものであっても、何かを提供するのに1週間以上かかることはありません。あなたが経験豊富なプログラマーで、2週間経っても何も配信しない場合、マネージャーはあなたが本当にスポーツニュースを読んでいるかどうかをどうやって知ることができますか？
だから、みんなの生活を楽にするために、何かを届けましょう。価値のあるものを提供するために、アプリケーション全体を理解する必要があるという態度をとらないでください。それは完全に誤りです。小さくてローカライズされたJavascript検証を追加することは、ビジネスにとって非常に価値があるかもしれません。それを提供すると、マネージャーは自分のお金にある程度の価値があることに安心します。さらに、それはあなたにスポーツニュースを読む時間を与えます。
時間が経つにつれて、5つの小さな修正を提供した後、アーキテクチャをゆっくりと理解し始めます。アプリの各側面を理解するために必要な時間を過小評価しないでください。認証を理解するために3〜4日かかります。トランザクション管理を理解するために2〜3日かかる場合があります。それは実際にはアプリケーションと同様のアプリケーションでのあなたの以前の経験に依存しますが、私はただ球場の見積もりを与えています。欠陥を修正する間の時間を盗みます。その時間を求めないでください。
何かを理解したら、メモを書くか、クラス/シーケンス/データモデル図を描きます。
ダイアグラム
はぁ...図について言及するのにとても時間がかかりました:)。私は、ランタイムシーケンス図を生成するツールであるMaintainJの作成者であるという開示から始めました。それがどのようにあなたを助けることができるかをあなたに話させてください。
メンテナンスの大部分は、問題の原因を特定すること、または機能がどのように機能するかを理解することです。
MaintainJで生成されたシーケンス図は、単一のユースケースのコールフローとデータフローを示しています。したがって、単純なシーケンス図で、ユースケースに対して呼び出されるメソッドを確認できます。したがって、バグを修正している場合、バグはおそらくこれらの方法の1つにあります。ただそれを修正し、それが他のものを壊さないことを確認して出て行ってください。
機能を拡張する必要がある場合は、シーケンス図を使用してその機能のコールフローを理解してから、拡張します。拡張は、フィールドの追加や新しい検証の追加などのようなものです。通常、新しいコードを追加することはリスクが少なくなります。
新しい機能を追加する必要がある場合は、開発する必要があるものと同様の他の機能を見つけ、MaintainJを使用してその機能の呼び出しフローを理解し、それを模倣します。
簡単に聞こえますか？実際には単純ですが、まったく新しい機能や、アプリケーションの基本的な設計に影響を与える何かを構築するなど、より大きな拡張を行う場合があります。そのようなことを試みるときまでに、アプリケーションに精通し、アプリのアーキテクチャをかなりよく理解している必要があります。
上記の私の議論に対する2つの警告
コードを追加する方が、既存のコードを変更するよりもリスクが少ないと述べました。変更を避けたいので、既存のコードを変更するのではなく、単に既存のメソッドをコピーして追加したくなるかもしれません。この誘惑に抵抗してください。すべてのアプリケーションには、特定の構造または「均一性」があります。コードの重複などの悪い習慣によってそれを台無しにしないでください。「均一性」から逸脱しているときを知っておく必要があります。プロジェクトの上級開発者に変更を確認するように依頼します。規則に従わないことを行う必要がある場合は、少なくともそれが小さなクラスに対してローカルであることを確認してください（200行クラスのプライベートメソッドがアプリケーションの美学を損なうことはありません）。
上記のアプローチに従うと、業界で何年も生き残ることができますが、アプリケーションアーキテクチャを理解できないリスクがあり、長期的には良くありません。これは、より大きな変更に取り組むか、Facebookの時間を短縮することで回避できます。少し自由になったときにアーキテクチャを理解し、他の開発者のためにドキュメント化するために時間を費やしてください。
結論
即時の価値に焦点を合わせ、それを実現するツールを使用しますが、怠惰にならないでください。ツールと図は役に立ちますが、それらがなくても実行できます。プロジェクトの上級開発者の時間をとることで、私のアドバイスに従うことができます。
これは、非常に優れた視覚化機能を備えた非UMLツールです。
クラス/メソッドごとのコード行を長方形の色/辺の長さにマッピングできます。クラス間の依存関係を表示することもできます。
http://www.moosetechnology.org/
良い点は、Smalltalkスクリプトを使用して、必要なものを表示できることです 。http ://www.moosetechnology.org/docs/faq/JavaModelManipulation
ここでは、そのような視覚化がどのように見えるかを見ることができます： http ://www.moosetechnology.org/tools/moosejee/casestudy
JUDE Community UMLは以前はJavaをインポートできましたが、現在はそうではありません。それは良い、無料のツールです。
あなたのアプリが本当に複雑な場合、私は図があなたをそれほど遠くまで運ばないと思います。ダイアグラムが非常に複雑になると、読みにくくなり、パワーが失われます。手作業で生成された場合でも、適切に選択された図で十分な場合があります。
すべてのメソッド、パラメーター、および戻り値を詳しく説明する必要はありません。通常、必要なのはオブジェクトまたはパッケージ間の関係と相互作用だけです。
これがトリックを行うことができる別のツールです：http： //xplrarc.massey.ac.nz/
依存関係グラフを使用してコード構造を視覚化するための非常に完全なツールであるJArchitectツールを使用し、 CQlinqを使用してデータベースのようにソースコードを参照できます。JArchitectはオープンソースの貢献者には無料です
私が使用するいくつかの素晴らしいツール-
StarUML（コードからダイアグラムへの変換を可能にします）
MS Visio
XMind（システムの概要に非常に役立ちます）
ペンと紙！
