ドキュメントなしで何千行ものコードを読み取る方法は？
以前は、WPFプロジェクトに適したTimeLineコントロールを探していました。 こちら で回答が見つかりました このCodePlexプロジェクト に移動します。
次に、カルチャのニーズを満たすためにコードを変更したいと思います。しかし、いくつかの不一致があります！
私の質問は：
このような数千行のコードをどのように操作しますか？
編集：
どんなショートカットも素晴らしいでしょう！
ソースコードにコメントを追加するには、ソースコードを理解できるようになったら、コメントを追加します。理解が深まるにつれ、これらのコメントを力強くリファクタリングしてください。
- コードをステップ実行
- 必要に応じて名前を変更
- 必要に応じてリファクタリング
- 完全に理解するまで繰り返します
...そしてコードはそれをありがとうでしょう。 ;-)
単一のアクションを実行し、コードをデバッグ（もう一度）して、そのアクションがどのように実行されるかを見つけます。同じことを簡単な言語で書き留めて、理解を深めましょう！
Joel Spolskyが彼のブログに書いたとき（今のところ記事を見つけることができません）は、これについて本当に私に固執しました。
彼は、コードは自然な人間の言語ではないことを述べたが、プログラマーとして、私たちはそれがそうであり、そのようにそれを読むことができるはずであると考えることに容易に落ち着きます。その結果、私たちの多くは新しいコードを見て、まるでそれが英語のテキストのブロックであるかのように、「それを読んで」すぐに理解できると期待しています。
だから私は鍵は基本的にただゆっくり、系統的、そして科学的であることだと思います。そして他の人が言ったように-あなたが行くときにそれをコメントします（そしてリファクタリングすらします）。 「見ればすぐわかる」という考え方に陥らないでください。
ああ、そうです、私はまだ自分でこの罠に陥ることがあります。 「私がするようにではなく、私が言うようにしてください」、そしてそのすべて。 :)
SE-RadioはDave Thomasにインタビューしました まさにこの主題について
このポッドキャストエピソードには、プロジェクトの「文化」に入り、元の住民がどのように住んでいたかを理解するための多くのヒントとテクニックがあります。
私は最近、10万件を超えるLOCのプロジェクトでこれを行わなければなりませんでした。私の最初のアイデアは、100,000行のテキストからよりも、100ノードまたは1000ノードのグラフからパターンを見やすくすることでした。
そこで、45分かけて短い（<100LOC）Pythonプログラムを作成し、そこから必要なものを解析してオブジェクトの関係を描画しました。 Graphviz ソースを生成しました。これは生成が非常に簡単な言語です（Pythonここでは特別なことはありません：RubyまたはC＃またはCommon LISPまたは同様にそれを行うことができる何でも。）
他のプロジェクトでは、モジュールの依存関係、呼び出しグラフ、バージョン履歴など、さまざまな目的でGraphvizを使用する人を見てきました。史上最高のプログラム視覚化メタツール。
（多分それは私が コンパイラーを取り出した からだと思いますが、プログラマーが問題に直面したとき、問題がソースに関係している場合を除いて、答えは常に「プログラムを書く！」プログラムへのコード。:-)
手がかりを使う必要があります。探す必要があるものの手がかりを取得し、環境の検索機能を幅広く使用するか、IDEこれにより、変更する必要があるコードの目的のセクションに移動できます。
Javaコードの14,000行を読むのは意味がありません。検索機能はあなたの命の恩人です
実行中にデバッガーでステップ実行します。これは、新しい大きなコードベースを理解するためのほぼ唯一の方法です。
満腹になるには本当に近道はないことを理解してください。 （そして、そのフレーズに問題がある場合、あなたの教育はまったく無視されています。それは、ロバートA.ハインラインによる「奇妙な土地の見知らぬ人」によるものです。）
一度に1ページずつ、一度に1つのルーチンで読んでください。コメントを追加します。主要なデータ構造の図を描きます。アルゴリズムを認識します。以前の知識を活用します。
デバッガーを起動する誘惑に抵抗します。デバッガのビューポートが小さすぎます。一度に1行しか表示されませんが、実際にはどこに行ったか、どこに向かっているかがわかりません。
あなたが何をするにせよ、あなたが進むにつれてできる限り多くを書き上げるので、誰もあなたがあなたが持っているのと同じ立場になることは決してありません。
コメント化されていないコードの大きなチャンクだけでなくすべてのプログラミングと同様に、最良の方法は、それを断片に分解することです。これは、頭の中で行うことと、コードで視覚的に行うことの両方です。これは、大きな太字のコメントまたは複数の改行を追加することを意味する場合があります。これは、スクロールしてピースを表示するときに役立ちます。コードの論理的なチャンクを見つけてみてください。
もちろん、ビットを理解したら、その時点で知っていることについてコメントを付け、おそらく理解できないことについてのメモを付けます。
作品全体を最初から理解しようとしないこともお勧めします。代わりに、今すぐに知っておく必要のある部分を理解し、残りの部分について後で作業してください。
Leo Editor を @ shadowモード で クローンノード を積極的に使用することから始めます。これにより、コードを変更せずに、調査中のコードの各セクションにメモとコメントを追加できます。注釈は、対象となるコードの隣に常にコンテキスト内にあります。ドキュメントのワークフローの例を次に示します。
たとえば、Leoのバグを修正する場合、そのバグを表す通常のノードを作成します。このバグノードは、バグに関連するレオのソースコード内のすべてのデータの私の見解です。バグに関連するコードを見つけたら、ノードのクローンを作成してバグノードの下に移動します。また、通常のノードをバグノードの子として追加します。これらのノードには、元のバグレポート、バグの修正方法の説明、テストデータ、または保持したいその他のメモが含まれています。
バグノードを作成したら、そのノードとその子にのみ集中します。アウトラインを飛び回ることなく、バグノードとその子を調べることができます。必要なものはすべて1か所にあります。実際にバグを修正するために移動したら、クローンを変更することで修正できます。繰り返しになりますが、アウトラインをあちこち飛び回る必要はありません。アウトライン全体の大きさや複雑さは関係ありません。私はバグノードとその子だけを扱います。この非常に狭い焦点により、バグの修正がはるかに簡単になります。
ソースの図を描きます：データの関係、機能の関係、オブジェクトの関係。集約、データフロー、およびコードフローを決定します。写真はこれに対するコメントよりもはるかに優れており、コードから分離しておくことができます。
何かをリファクタリングする前に、テストを書いてください。たくさんのテスト。継承された混乱がどのように記述されているかに依存するため、少なくとも呼び出し可能なコードの小さなブロックに対する非常に具体的なテスト。
最初にテストを作成する利点は、コードをテストする前にコードをある程度理解する必要があることです。そのため、作成するすべてのテストで少しずつ知識が得られるはずです。アサーションと一緒に仮定を使用してテストに強くコメントすることもできます。
最初にテストを行うことで、コード内で、知らないノックオン効果を持つ何かを変更するリスクを負うことはありません。また、コードをリファクタリングするときにも、セーフティネットを利用できます。
私はdoxygenなどのツールを使用して全体的なクラス図を生成しますが、各クラスの機能についての理解を深めます。
次に、バグキューからいくつかの簡単なバグをピックアップし（マネージャーがハードバグを割り当てる前に：P）、その機能を実行してデバッガーに移動し、大まかなデータフローまたはコードフローモデルを生成します。
たとえば、一部のソフトウェアのエクスポート機能：コード（基本インターフェイス）のどこからソースデータが読み取られるかを理解しようとしています。クラスとコードフロー図を使用して、データが正しく読み取られたかどうかを評価できます。クラスダイアグラムとフローチャートが得られたら、理解の半分は完了したと思います。
人によって学習スタイルが異なるため、YMMVを使用します。この状況で私が最初に行うことは、コードベース全体を少なくとも1回は読み取ることです。それは私にすべてがどこにあるかの一般的な考えを与えます。次に、セクションを選択してさらに詳しく調べます。まずはデータ構造から始めるのがよいでしょう。何が起こっているのかを大まかに把握したら、最初のコードと相互作用するコードの別の部分でも同じことを行います。十分な反復の後、コードがどのように機能するかを十分に理解できました。
些細な欠陥（NullPointerExceptionなど）にアプローチします。最初は、並行性に関することは何も避けてください。本質的に、一度に多くのコードを理解する必要があるものは避けてください。
いくつかのバグを修正したら、かなり良いアイデアが得られるでしょう。とにかく私のために働く。