外部コードに慣れる
コードベースが十分に小さければ、すぐに読み始めることができます。ある時点で、破片が一緒に落ち始めます。
このシナリオでは、「十分に小さい」はさまざまで、経験が増えるにつれて大きくなります。また、ここで「不正行為」の恩恵も受け始めます。経験から「パターン X の実装」として認識しているコードの断片をスキップできます。
コードを読んでいる間、ちょっとした回り道をするのが役に立つかもしれません。例えば、関数が呼び出されているのを見て、それをざっと見てみるなどです。呼び出された関数が何をするかを理解するまで、これらの回り道にとどまらないでください。これはポイントではなく、飛び跳ねて進歩していないように感じます。迂回するときの目標は、新しい機能が何をするのかを 30 分以内に理解することです。できない場合は、機能が複雑すぎることを意味します。回り道をやめて、この余分な助けなしに「現在の」機能を理解する必要があるという事実を受け入れてください。
コードベースが大きすぎると、すぐに読み始めることができません。この場合、高レベルの抽象化でプログラムの論理コンポーネントを識別することから始めることができます。目標は、ソース コード内の型 (クラス) をこれらのコンポーネントに関連付けてから、各クラスがそのコンポーネントで果たす役割を特定することです。コンポーネント内で使用されるクラスと、他のコンポーネントまたはフレームワークとの通信に使用されるクラスがあります。ここで分割して征服します。まずクラスを関連するグループに分割し、次にグループに注目して、その部分がどのように組み合わされるかを理解します。
この作業を支援するために、ソース コードの構造をガイドとして使用できます (究極の法則としてではなく、人的ミスにより誤解を招く場合があります)。関数や型の「使用箇所の検索」などのツールを使用して、それぞれがどこで参照されているかを確認することもできます。繰り返しになりますが、合理的に迅速に実行できない場合は、IDE が指示する内容を完全に消化しようとしないでください。これが起こるとき、それはあなたが完全に理解していない機械から複雑な金属片を選んだことを意味します. 理解できるものが見つかるまで、元に戻して別のことを試してください。
外部コードのデバッグ
これはまったく別の問題です。私は少しごまかしますが、大量の経験を積むまでは、コードが自分にとってなじみのないものである限り、コードのデバッグを成功させる方法はありません。