コードの構造をどのように視覚化する必要がありますか？
Javaで書かれたアプリケーションがあります。でいくつかのファイルに格納されます。それは、異なるメソッドを持つ異なるクラスを使用します。コードは大きくて複雑です。コードのグラフィカルモデル（ある種の有向グラフ）があれば、コードを理解する方が簡単だと思います。コードを視覚化するための標準的な方法はいくつかありますか？ UMLの使用について考えています（正しい選択かどうかはわかりません）。誰かが何か私をお勧めできますか？
追加：
2つの可能性を検討します。
- 手作業でグラフを作成する（明示的に）。
- 自動でグラフを作成します。たとえば、利用可能なコードを読み取り、コードの構造を説明するグラフを生成するツールを使用します。
追加2：
無料で何かを持っているといいですね。
使用する必要がある最も重要なツールは脳であり、無料です。
標準的な視覚化方法を使用する必要がある理由はなく、好きなメディアを使用できます。紙、ホワイトボード、フォトショップ、Visio、PowerPoint、メモ帳：これらはすべて効果的です。クラス、オブジェクト、メソッド、プロパティ、変数の図を描きます-アプリケーションを理解するために見たいと思うものは何でも。聴衆はあなたのチームの他のメンバーだけでなく、あなた自身でもあります。見て、すぐに理解するのに役立つ図を作成します。それらをワークスペースの周りに投稿し、定期的に確認して、構築中の全体的なシステムアーキテクチャを思い出してください。
UMLおよびその他のコードドキュメント標準は、実行できる図の種類と、含めることを検討する必要がある情報についての優れたガイドラインです。ただし、それはほとんどのアプリケーションにとって過剰であり、基本的に標準化なしに文書化する個人的な責任を負うことができない人々のために存在します。 UMLに従っている場合、アプリケーションを作成するのではなく、ドキュメントに多くの時間を費やしてしまうことになります。
多くのUMLツールを使用してみましたが、ほとんどのUMLツールのリバースエンジニアリング機能は、コードの理解に役立たないことがわかりました。彼らは、ニーズの設計とリバースエンジニアリング機能に焦点を当て、多くの場合、多くの役に立たない情報の巨大な写真を表示するだけです。 Microsoft Officeのコードベースで作業していたときに、ペンと紙を使用する方が、一般的なデザイン/モデリングツールよりも便利であることがわかりました。
通常、これをいくつかの方法で行うことを検討します。
- 頭を使う：他の誰かがそれを述べました-実際にコードベースを理解しようとすることに代わるものはありません。メモを取り、後で参照する必要がある場合があります。ツールは役に立ちますか？間違いなく。しかし、彼らがあなたのためにほとんどの仕事をすることを期待しないでください。
- ドキュメントを見つけて同僚と話す：いくつかのソースにコードベースの主要な概念を説明させるより良い方法はありません。あなたを助ける人を見つけることができるなら、ペンと紙を持って、彼のところに行き、たくさんのメモを取ってください。他の人をどれくらいバグさせるか？初めに-あなたの仕事にとって実用的ですが、量が少なすぎることはありません。
- ツールについて考える：プロジェクトの一部に不慣れな場合-コードの理解にかなりの時間を費やすことになるので、自動的に取得できるヘルプを確認してください。良いツールと悪いツールがあります。最初に役立つ可能性のある機能を備えたツールを見つけてください。上で述べたように、平均的なUMLツールはモデリングに重点を置いており、適切ではないようです。
- 時間vsコスト：もちろん、無料は素晴らしいです。しかし、無料のツールを多くの人が使用していない場合は、ツールが機能しない可能性があります。何ができるかを探る目的で作成されたツールはたくさんありますが、実際には役に立たないため、他の誰かがそれを採用することを期待して無料で提供されています。それについて考えるもう1つの方法は、時間の価値を決定することです。1日か2日かけてツールが機能するようにすることは理にかなっています。
そこに到達したら、プロジェクトを理解しようとするときは、これらを覚えておいてください。
- マイルハイビュー：階層化されたアーキテクチャ図は、プロジェクトのメインコンセプトが相互にどのように関連しているかを知るのに非常に役立ちます。 LattixおよびArchitexaのようなツールは、ここで非常に役立ちます。
- The Core ：main conceptsに関してコードがどのように機能するかを理解してください。ここではクラス図が非常に役立ちます。ペンと紙はここで十分に機能しますが、ツールはプロセスをスピードアップするだけでなく、そのような図を保存して共有するのにも役立ちます。 AgileJとArchitexaが最善の策だと思いますが、平均多くの場合、UMLツールで十分です。
- 主な使用例：アプリの主な使用例を少なくとも1つ追跡することをお勧めします。チームの誰からも最も重要なユースケースを取得できる可能性が高く、それを実行することは非常に役立ちます。ほとんどのIDEはここで本当に役立ちます。それらを描画しようとする場合、シーケンス図が最も適切です。ここのツールについては、MaintainJ、JDeveloperおよびArchitexaが最善の策です。
注：私はArchitexaの創設者です-私たちはあなたを助けるためのツールを構築します理解して文書化Java codeですが、私は私の意図は、これが私の博士号の一部として私が焦点を合わせたものであるという前提で、ツールとオプションを提案することです。
複数のファイルに保存されています。それは異なるメソッドで異なるクラスを使用します。コードは大きくて複雑です。
すべてのJava学校の外で書かれたコードは、特にプロジェクトを始める新しい開発者にとってはそうです。
これは古い質問ですが、Googleの検索で取り上げられるので、将来の訪問者に役立つようにここに私の回答を追加します。私が MaintainJ の作成者であることも開示させてください。
アプリケーション全体を理解しようとしないでください
質問させてください-なぜコードを理解したいのですか？ほとんどの場合、バグを修正するか、アプリケーションの機能を拡張しています。最初にやるべきでないことは、アプリケーション全体を理解することです。プロジェクトをやり直しながら、アーキテクチャ全体を理解しようとすると、圧倒されます。
私がこれを言ったとき私を信じてください-10年以上の確かなコーディング経験を持つ開発者は、1年以上同じプロジェクトに取り組んだ後でさえ、アプリケーションの特定の部分がどのように機能するか理解できないかもしれません（彼らが元の開発者でないと仮定します）。認証がどのように機能するか、アプリケーションでトランザクション管理がどのように機能するかを理解していない可能性があります。 1000から2000までのクラスを持ち、さまざまなフレームワークを使用する典型的なエンタープライズアプリケーションについて話しています。
大規模アプリケーションを維持するために必要な2つの重要なスキル
それでは、彼らはどのようにして生き残り、多額の支払いを受けますか？経験豊富な開発者は通常、自分が何をしているかを理解しています。つまり、バグを修正する場合は、バグの場所を見つけて修正し、アプリの残りの部分が壊れないようにします。機能を拡張したり、新しい機能を追加したりする必要がある場合は、ほとんどの場合、同様の機能を持つ既存の機能を模倣する必要があります。
これを行うのに役立つ重要なスキルが2つあります。
彼らは、バグを修正するときに行う変更の影響を分析できます。最初に問題を特定し、コードを変更してテストし、機能することを確認します。次に、Java=言語とフレームワークが十分に理解しているため、アプリのその他の部分が破損するかどうかを判断できます。そうでない場合は、完了です。
私は、アプリケーションを強化するために単に模倣する必要があると述べました。効果的に模倣するには、Javaをよく理解し、フレームワークを「十分に」理解する必要があります。たとえば、新しいStrutsアクションクラスを追加して構成XMLに追加する場合、最初に同様の機能を見つけて、その機能のフローをたどり、機能がどのように機能するかを理解してください。構成の一部を微調整する必要がある場合があります（「フォーム」データが「セッション」スコープではなく「リクエスト」にあるなど）。彼らがフレームワークを「十分」に知っていれば、簡単にこれを行うことができます。
一番下の行は、バグを修正したり、アプリを拡張したりするために2000クラスすべてが何をしているかを理解する必要がないです。何が必要かを理解してください。
即時の価値の提供に重点を置く
それで、私はあなたにアーキテクチャを理解することを思いとどまらせていますか？いいえ、まったく違います。私があなたに求めているのは配達することだけです。プロジェクトを開始し、PCに開発環境をセットアップしたら、何かを提供するのに1週間以上かかることはありません。あなたが経験豊富なプログラマーであり、2週間後に何も配信しない場合、マネージャーがあなたが本当に働いているか、またはスポーツニュースを読んでいるかをどうやって知ることができますか？
だから、誰にとっても生活を楽にするために、deliver何か。何か価値のあるものを提供するためにアプリケーション全体を理解する必要があるという態度には従わないでください。それは完全に誤りです。小規模でローカライズされたJavascript検証を追加することは、ビジネスにとって非常に価値があるかもしれません。あなたがそれを提供するとき、マネージャーは彼が彼のお金にいくらかの価値を得ていると安心します。さらに、スポーツニュースを読む時間も与えられます。
5つの小さな修正を提供してから時間が経つにつれ、アーキテクチャをゆっくりと理解するようになります。アプリの各側面を理解するために必要な時間を過小評価しないでください。認証を理解するには3〜4日かかります。トランザクション管理を理解するには、2〜3日かかる場合があります。それは実際にはアプリケーションと同様のアプリケーションでの以前の経験に依存しますが、私は概算を推定しているだけです。欠陥を修正する間の時間を盗みます。その時間を求めないでください。
何かを理解したら、メモを書くか、クラス/シーケンス/データモデル図を描きます。
図
Haaa ...ダイアグラムに言及するのにとても時間がかかりました:)。私は、ランタイムシーケンス図を生成するツールである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 ツールを使用すると、 dependency graph を使用してコード構造を視覚化し、データベースのように CQlinq を使用してソースコードを参照できます。 =。 JArchitectは無料です オープンソースの貢献者
私が使用するいくつかの優れたツール-
StarUML（コードからダイアグラムへの変換を許可）
MS Visio
XMind（システムの概要に非常に役立ちます）
ペンと紙！