ドキュメントなしで何千行ものコードを読むには？[閉まっている]

以前は、WPFプロジェクトに適したTimeLineコントロールを探していました。ここでこのCodePlexプロジェクトに導く答えを見つけました。

次に、文化のニーズを満たすためにコードを変更します。しかし、いくつかの不一致があります！

私の質問は：

このような数千行のコードをどのように操作しますか？

編集：

どんなショートカットも素晴らしいでしょう！

ソースコードに理解できるようになったら、コメントをソースコードに追加します。理解が深まるにつれて、これらのコメントをリファクタリングしてください。

1. コードをステップ実行する
2. 必要に応じて名前を変更
3. 必要に応じてリファクタリング
4. 完全に理解するまで繰り返します

...そして、コードはあなたに感謝します。;-)

単一のアクションを取り、コードをデバッグ（もう一度）して、そのアクションがどのように達成されるかを見つけます。同じことを簡単な言語で書き留めて、理解を深めてください！

Joel Spolskyが彼のブログに戻ったときに書いたもの（今は記事を見つけられません）が、これに関して本当に私にこだわっています：

彼は、コードが人間の自然な言語ではないことを言ったが、プログラマーとして、私たちはそれがそうであり、それをそのように読むことができるべきだと考えるようになりやすい。その結果、私たちの多くは新しいコードを見て、まるでそれが英語のテキストのブロックであるかのように、ただ「読んで」すぐに理解できることを期待しています。

ですから、基本的には、ゆっくり、系統的、科学的にすることが重要だと思います。そして、他の人が言ったように-あなたが行くようにそれをコメントし（そしてリファクタリングさえ）。「私はただそれを見てすぐに理解すべきだ」という考え方に陥らないでください。

ああ、はい、私はまだ時々自分自身でこのtrapに陥ります。「私が言うように、私がやるのではなく」:)

SE-Radio はこのまさに主題について Dave Thomasにインタビューしました

このポッドキャストエピソードには、プロジェクトの「文化」を入力し、元の住民の生活を理解するための多くのヒントとテクニックが含まれています。

最近、100,000を超えるLOCのプロジェクトでこれを行う必要がありました。私の最初のアイデアは、100,000行のテキストよりも100または1000ノードのグラフからパターンを見る方が簡単だということでした。

そのため、45分を費やし、必要なものを解析してオブジェクトの関係を引き出すために、短い（<100LOC）Pythonプログラムを作成しました。Graphvizソースを生成しましたが、これは本当に簡単です生成するための言語を。（ここでPythonについて特別なことは何もありません。Ruby、C＃、Common Lisp、または同様にそれを行うことができるものは何でも。）

他のプロジェクトでは、モジュールの依存関係、コールグラフ、バージョン履歴、あらゆる種類のものにGraphvizを使用している人を見てきました。史上最高のプログラム可視化メタツール。

（たぶん、コンパイラを使用したからかもしれませんが、プログラマーが問題に直面したとき、問題がプログラムのソースコードに関係している場合を除いて、答えは常に「プログラムを書いてください！」 ）

デバッガーを実行しながらステップ実行します。これは、新しい大規模なコードベースを理解するためのほぼ唯一の方法です。

完全にグロッキングするための近道は本当にないことを理解してください。（そして、あなたがそのフレーズで問題を抱えているならば、あなたの教育は全く無視されました。それはロバート・A・ハインラインによる「ストレンジャー・イン・ア・ストレンジ・ランド」からです。）

一度に1ページ、ルーチンを1つずつ読んでください。コメントを追加します。主要なデータ構造の絵を描きます。アルゴリズムを認識します。以前の知識を活用してください。

デバッガを起動する誘惑に抵抗してください。デバッガのビューポートは小さすぎます。一度に1行ずつ表示されますが、実際にどこに行ったのか、どこに行ったのかはわかりません。

あなたが何をするにしても、できる限り書き上げて、だれもあなたが持っているのと同じ立場にならないようにします。

手がかりを使用する必要があります。探しているものの手がかりを取得し、環境またはIDEの検索機能を広範囲に使用して、変更が必要なコードの目的のセクションに移動できます。

14,000行のJavaコードを読むことは意味がありません。検索機能はあなたの命の恩人です

人によって学習スタイルが異なるため、YMMV。この状況で最初に行うことは、少なくとも一度はコードベース全体を読み取ることです。それは私がすべてがどこにあるかの一般的なアイデアを提供します。次に、セクションを選択して詳細を調べます。データ構造は、開始するのに適した場所です。何が起こっているかについての一般的な考えが得られたら、最初のコードとやり取りするコードの別の部分についても同じことを行います。十分に繰り返した後、コードがどのように機能するかを十分に理解しています。

コメントなしのコードの大きな塊だけでなく、すべてのプログラミングと同様に、最善の方法は、断片に分割することです。これは、コードで視覚的に行うだけでなく、頭の中で行うべきことです。これは、大きな太字のコメントまたは複数の改行を追加することを意味する場合があります。これは、スクロールして作品を見るのに役立ちます。コードの論理的なチャンクを見つけてください。

もちろん、ビットを理解したら、その時点で知っていることについてコメントし、おそらくあなたが理解していないことについてメモを入れてください。

また、最初から全体を理解しようとしないことをお勧めします。代わりに、今すぐ知る必要のある部分を理解し、残りの部分については後で作業してください。

クローンノードを積極的に使用して、@ shadowモードでLeo Editorを使用することから始めます。これにより、コードを変更することなく、調査中のコードの各セクションにメモとコメントを追加できます。また、注釈は、それが話しているコードの隣に常にコンテキスト内にあります。ドキュメントのワークフローの例を次に示します。

たとえば、Leoのバグを修正するとき、バグを表すために通常のノードを作成します。このバグノードは、バグに関連するLeoのソースコード内のすべてのデータの私の見解です。バグに関連するコードを発見したら、それらのノードのクローンを作成し、バグノードの下に移動します。また、通常のノードをバグノードの子として追加します。これらのノードには、元のバグレポート、バグの修正方法の説明、テストデータ、または保持したいその他のメモが含まれています。

バグノードを作成したら、そのノードとその子だけに集中します。アウトラインを飛び回る必要なく、バグノードとその子を調べることができます。必要なものはすべて1か所にあります。バグを実際に修正できるようになったら、クローンを変更することで修正できます。繰り返しますが、アウトラインを飛び回る必要はありません。アウトライン全体の大きさや複雑さは関係ありません。バグノードとその子だけを扱っています。この非常に狭いフォーカスにより、バグの修正がはるかに簡単になります。

ソースの図を描く：データ関係、機能的関係、オブジェクト関係。集約、データフロー、およびコードフローを決定します。これに対するコメントよりも写真の方がはるかに優れており、コードとは別に保管することができます。

リファクタリングする前に、テストを作成します。多くのテスト。継承された混乱の記述方法に依存するため、少なくとも呼び出し可能なコードの小さなブロックに対する非常に具体的なテスト。

最初にテストを作成する利点は、テストする前にコードをある程度理解する必要があるため、作成するすべてのテストが少しでも知識を得られることです。また、アサーションと一緒に仮定を使用してテストにコメントすることもできます。

最初にテストを実行することで、知らないノックオン効果を持つコード内の何かを変更するリスクを負うことはありません。また、コードをリファクタリングする際にセーフティネットも用意されています。

私はdoxygenのようなツールを使用して、全体のクラス図を生成し、各クラスが何をするのかを理解します。

次に、バグマネージャーから簡単なバグを見つけて（マネージャーがハードバグを割り当てる前に：P）、その機能をデバッガーで実行し、大まかなデータフローまたはコードフローモデルを生成しようとします。

たとえば、一部のソフトウェアのエクスポート機能：ソースデータの読み取り方法を理解しようとしています。コード（ベースインターフェイス）のどこから、クラスとコードフロー図を使用してデータが正しく読み取られるかを評価できます。どのタイプのエクスポートなど。クラス図とフローチャートを作成したら、理解の半分が完了したと思います。

NullPointerExceptionなどの些細な欠陥にアプローチします。最初は並行性に関することは避けてください。その性質上、一度に多くのコードを理解する必要があります。

いくつかのバグを修正したら、おそらくかなり良いアイデアがあるでしょう。とにかく、私のために働く。

基本的に、クリーンなコードを記述するアクションは、設計からすぐに開始する必要があります。OOP言語でコーディングしている場合、UMLを作成し、ピアと共有して、デザインが曖昧でないことを確信します。いずれにせよ、開発者は、デザインが曖昧さではなく問題を解決することを確信する必要があります。

コーディングに関しては、デザインがコードに変換されていることを確認する必要があります。つまり、エンティティーをクラスまたは構造体に、機能を操作するなどです。

そして、ホワイトペーパーhttp://queue.acm.org/detail.cfm?id=2063168に目 を通しました。これは、コーディングスタイルや、スペース、インデント、ほとんどのIDEで使用できるフォントバリエーションの使用方法について説明しています。人間が機械と同じくらい理解できるクリーナーコード。コメントフリーのコードを書くことにより、コード自体が段落として表示されるようになります。