Vasyaは若いプログラマーです。 タスクを受け取り、袖をまくり、コードを受け取ります。 1日で、問題の解決策が整い、Vasyaはそれを開始します...そして、彼は予期しない迷惑なエラーに直面しています。 Vasyaは慎重に彼女を修正し、ソリューションを再起動します。 結果は再び不快な間違いです。 そこで、Vasyaは長い間レーキを踏んで、プログラムを数回大幅に書き直し、最終的には1週間でタスクが解決しました。



Petyaは経験豊富なプログラマーです。 定式化を受けて、彼は同様の問題を解決するソースコードを検索します。 Petyaは資料を読んで他の人のモジュールを理解するのに2、3日費やし、3日目-既存のコードに基づいてソリューションを立ち上げます。 いくつかの軽微なエラーがあり、すぐに修正できます。 やった！ 3日目にすべてが正常に機能します。



必要なソースコードを見つける方法 彼を理解する方法は？ そして最も重要なこと-なぜこれをすべて行うのですか？ これらの質問に対する答えを探して、猫へようこそ。

コードを検索して読み取ることが重要なのはなぜですか？

D. ThomasとD. Spinellisは、 「オープンソースプロジェクトの例に関するプログラムコードの分析」という本で、いくつかの重要なポイントを定式化しています。



コードを読むことはプログラマーの毎日のルーチンです。



側から見ると、プログラマーの主な仕事はソースを書くことだと思われますが、そうではありません。 ほとんどの場合、コードは書き込まれるのではなく、読み取られる必要があります。 昨日あなたの友人はモジュールを書きました、そして今日、あなたはそれを改善するか、あなたの友人の作品の予備研究なしでは不可能である間違いを修正する仕事に直面しています。



コードの読み取り時にエラーの90％を排除できます。



90％という数字では、議論の余地があるように思えますが、主なアイデアは明確です：プログラムを読んでいる（この場合はレビューしている）とき、エラーを特定して排除することが可能です（そして必要です）。



私たちはしばしばコードを書くことを教えられますが、めったに-それを読むことを教えられません。



また、既存のソースを読むことなく、常に車輪を再発明する必要があるため、無駄です。 ゼロから何かを書くことができたとしても、他の人のソースコードを直接、または類推して見て回る方がはるかに効率的です。 外部コードはチェック、デバッグされており、ほとんどの場合、すでに問題の解決に役立ついくつかの「機能」が含まれています。



だから、自転車を書かないようにコードを読んでください。 コードを読んで、変更を高速化してください。 プログラムのエラーが少なくなるようにコードを読んでください。

この記事は何についてですか？

この記事の主な目標は、コードの検索と読み取りに対する既存のアプローチを体系化することです。 特定のアプローチの知識により、特定のケースで最も受け入れられるアプローチを適用できます。 さらに、この記事では、この記事で説明されているアプローチを効果的に適用するツールの概要を提供します。 特別なツールがなくてもソースコードを検索して理解できることは注目に値しますが、その使用によりプロセスがより視覚的になり、ルーチンが少なくなります。



最も普遍的な概念について説明します。つまり、これらの概念は、すべてまたはほとんどすべてのプログラミング言語に適用されます。 ソースの検索と読み取りを容易にするツールも普遍的ですが、それらのほとんどはVisual Studioと.NETにのみ関連しています。 それにもかかわらず、ほとんどのツールがVSでのみ使用されているという事実は、他のIDEにそのようなツールがないことを意味するものではありません。 また、説明されているすべてのツールが無料であることを予約します。例外はReSharperのみです。



この記事のコード例は、2015年6月30日時点のShareXリポジトリからのShareXおよびGreenshot アプリケーション （両方ともGNU GPLライセンスで配布されています ）から取られたものです。 同僚、特にデニス・ガヴリロフとヴラディスラフ・イオフェにも、記事の執筆中にコメントしてくれたことに感謝します。

コード検索

コード検索はプロセスであり、その結果は解決される問題の主題に関連するソースコードの一部です。

コード外検索

コードベース外のソースコードの検索を開始することは可能であり、必要です。 チームとの予備的なコミュニケーション、ドキュメントの読み取り、バグトラッカーにより、コードの直接検索が大幅に簡素化されます。 アーティファクトの操作に関する詳細については、D。Gavrilovによるワークショップ「チーム作業の実践：アーティファクトの記述の利点」を参照してください 。 ドキュメントを読んでチームとやり取りすることに加えて、まだ発見されていないものについて既に知っていることを思い出しておくと便利です。 たとえば、画面フォームを検索する必要がある場合、プロジェクト内の画面フォームの名前は通常Formで終わり、すべてのフォームは「UI」で組み立てられることを覚えておく価値があります。



実行のためにアプリケーションを実行し、ブルートフォースで画面フォームを検索できます。 繰り返し処理を行うとき、プログラマは、ウィンドウ、ボタン、メニュー項目、または目的の機能を使用していると思われるその他のインターフェイス要素を見つけるまで、フォームのランダムな（またはそれほどではない）順序で開きます。 検索タスクがぼやけているか、プログラマーがシステムを初めて使用する場合、バスティングが適用されます。 たとえば、アプリケーションを使用したことがなく、開いているすべての画像をクリップボードにエクスポートする関数を追加する必要があります。 そもそも、アプリケーションを調べるのは理にかなっているようです。一度に1つずつクリップボードに画像をエクスポートできるかどうか、バッファーやエクスポートに関連する設定があるかどうかなどを確認してください。

キーワード検索

キーワードは、情報検索の観点から重要な意味的負荷を運ぶ文書またはリクエストのテキストからの単語またはフレーズです。 検索に必要なキーワードの選択は、ユーザーとのコミュニケーション、ブルートフォースによる画面フォームの表示、および「コード外」の検索として上記で説明した他の方法によって形成されます。 キーワードは、タスクの説明、画面のフォームおよびユーザーアクション、エラーまたはメッセージのテキスト、SQLクエリ、つまり、解決されるタスクに関連するアーティファクトから取得できます。



キーワードによる検索が可能な限り効果的であるためには、まれなキーワードを選択する必要があります。 たとえば、多くの異なるドキュメント（ドキュメント）があるプロジェクトで作業している場合、「ドキュメント」という単語を検索すると、多くの不要な結果が得られます。 ただし、まれなキーワードを見つけることができない場合があります。 この場合、最初に多くの潜在的に有用な情報を見つけてから、検索を絞り込む必要があります。 たとえば、Documentへのすべての既存の参照を見つけて、結果からテストを除外し、見つかったファイルで追加のキーワードを探します。一般に、それだけでなく、少なくとも何か（少し多かれ少なかれ）を見つけようとする必要があります。必要なもの。



ほとんどの場合、IDEに組み込まれている検索はキーワードで検索するのに十分です（通常はCtrl + Fで呼び出されます）。 ファイルマネージャーは、ソフトウェアソリューションに含まれていないフォルダーを検索する場合や、 OpenGrokやDocFetcherなどの検索エンジンを検索する場合に役立ち ます （以下で説明します）。 したがって、ReSharperには便利なパターンによる検索機能が含まれており、たとえば、ゼロ列挙として宣言されたすべてのクラスプロパティ（public TEnum？Enum {get; set;}）を見つけることができます。 もちろん、正規表現の強力なメカニズムを忘れないでください。 はい、必要になることはめったにありませんが、時には大いに役立ちます。



ソースコードで動作する検索エンジンについてもう少し話しましょう。 検索エンジンの主な利点は、柔軟な検索が可能なことです。 たとえば、クリップボードと画像に言及するすべてのクラスを見つける必要があります。 IDEに組み込まれた従来のツールを使用すると、クリップボードファイルまたはイメージファイルを見つけることができます。 ここで、悪名高い正規表現メカニズムを括弧の外に残します。これは役立ちますが、検索コンストラクトは面倒です。 組み込みの検索ツールでは対処できないより複雑な例：属性Aでマークされているが属性Bでマークされていないクラスプロパティを見つける必要性。検索エンジンは柔軟性に加えて、検索速度を向上させます。 IDEがプロジェクトのすべてのファイルを処理するのに数回、場合によっては12秒以上必要な場合、検索エンジンにはインデックスがあり、1秒で同じことができます。



ソースコードにはさまざまな検索エンジンがあります。StackOverflowの説明を読むか、Webサイトbeyondgrep.comで選択内容を確認してください。 私の仕事ではOpenGrokを使用しています 。これは無料であり、C＃、C、PHP、SQLなどのさまざまな言語で動作します。 このエンジンは、ソースインデックスモジュールと、コードを検索してナビゲートするためのWebアプリケーションの2つのモジュールで構成されています。 最初のモジュールは、ファイルシステム内のプロジェクトフォルダーにインデックスを付けます。 WebアプリケーションはApacheで実行され、さまざまな検索クエリを入力して結果を表示できます。 OpenGrokはJavaで書かれており、プロジェクトの公式Webサイトからダウンロードできます。関連記事では、 WindowsおよびLinuxで エンジンをインストールする方法について読むことができます。



OpenGrokはさまざまなタイプの検索をサポートします。ドキュメント全体のテキストで、または定義のみ、つまりクラスと関数の名前で。 さらに、フォルダーのフィルタリングと、探しているファイルの名前を設定したり、コードを記述する言語を選択したりできます。このエンジンは、ファイルごとにグループ化された視覚的な形式で結果を表示し、ワンクリックで目的の行に移動することもできますファイルをバックライト付きまたは「生の」形式で表示できます。





ShareXによるOpenGrok検索クエリと検索結果



OpenGrokにはいくつかの制限があります。1つ目はVisual Studioとの統合がないこと、2つ目はキリル文字の使用方法がわからないことです（少なくとも、設定を使用してこれを実現できませんでした）。 頻繁にロシア語のテキストを検索する必要がある場合は、 DocFetcherを使用できます。このツールは、ソースを検索して直接シャープにすることはできませんが、テキストファイルのインデックスを作成でき、ロシア語に完全に対応します。



以下の表は、検索エンジンOpenGrokとDocFetcherの機能を比較しています。

分類子による検索

分類子は、名前付きオブジェクトの体系的なリストです。 私の意見では、プログラマに最も人気のある分類子は、ソフトウェアソリューションのすべてのクラスのリストです。 他の分類子の例としては、クラスでソートされたクラスのメンバーのリスト、フォルダーでソートされたファイルのリストなどがあります。





ShareXアプリケーションクラス



一方では、分類子はツリーリストを操作するためのツールとして使用できます。 ソフトウェアソリューションのベースネームスペースを「拡張」し、目的のモジュールのネームスペースを「拡張」し、最終的に目的のクラスに到達するまで続きます。 一方、エンドツーエンド検索は分類子内で実行できます。 たとえば、* Document *と入力すると、分類子はDocumentが検出された名前のすべてのクラスを表示します。



ReSharperを使用している場合は、Go to Everything関数についておそらく知っているでしょう。これにより、ソフトウェアソリューション全体の任意のクラス、メソッド、プロパティ、またはファイルに移動できます。 Visual Studioには、ソリューションエクスプローラー（アセンブリ、フォルダー、ファイル、クラス、およびそのメンバーを分類）、クラスビュー（名前空間、クラス、およびそのメンバーを分類）、およびオブジェクトブラウザー（アセンブリ、名前空間、クラスを分類）およびそのメンバー）。 ソリューションエクスプローラーとクラスビューは、ソリューション内のクラスのリスト、およびソリューションと使用されているサードパーティアセンブリの両方のオブジェクトブラウザーを提供します。 OpenGrokでは、ワイルドカード（*ドキュメント*）の使用を含め、定義（定義）で検索できます。 別の分類子は、フォルダーに配置されたアーティファクトを表示する通常のファイルマネージャーです。



分類子はいつ使用する必要がありますか？ 分類子を正常に使用するには、プログラマーがソフトウェア製品について十分な知識を持っている必要があります。 特に、命名規則（たとえば、* Formはオンスクリーンフォームであり、DocumentNameListFormはDocumentNameタイプのドキュメントのリストフォームです）、およびクラスがフォルダーおよび名前空間に編成される原則（ディクショナリーにディレクトリがあります）、およびドキュメント内-ドキュメント）。 分類子による検索を適用する別の可能性は、クラスまたはそのメンバーの正確な名前がわかっている状況です。

エラー検索

定期的に、何らかのエラーが発生するコード行を見つけるタスクが発生します。 または、既知のエラー番号で目的の行を見つけることができます。 この場合、エラー番号は、検索が実行されるキーワードです（キーワードによる検索については上記で説明しました）。 別の状況では、エラースタックのトレースがわかっている場合があります。 ReSharperにはStack Tracesと呼ばれる便利なツールがあります。これにより、スタックを表示し、エラーが発生する前に呼び出されたメソッドをナビゲートできます。 スタックトレースを使用するには、エラースタックをクリップボードにコピーし、Visual StudioでShift + Ctrl + Eを押す必要があります。





Stack TracesでShareXスタックを表示およびナビゲートする



エラー番号またはスタックトレースに関する情報がない場合は、プロジェクトを開始し、誤って割り込みを有効にすることができます。 Visual Studioは、 Exception Breakerの便利なアドオンを作成しました。これにより、ワンクリックで誤って割り込みをオンまたはオフにできます。

ユーザーアクションによる

ボタンが押されたとき、または別のユーザーアクションが呼び出されたときにどのメソッドが呼び出されるかを調べることが必要な場合があります。 この場合、呼び出されたメソッドが存在するクラスを最初に見つけて（たとえば、キーワードまたは分類子で検索して）、次にこのクラスのすべてのメンバーにブレークポイントを設定して、アプリケーションを起動できます。 Webアプリケーションでは、場合によってはFiddlerが役立つことがあります。特に、呼び出されたWCF関数の名前とそれに渡されたパラメーターの値を確認できます。

まとめ

コードの検索を開始する前に、チームと通信し、ドキュメントを読み、画面フォームを並べ替えるのに少し時間をかける必要があります。 これは、キーワードを収集し、クラスとメソッドの名前を見つけるために必要です。これがないと、それ以上の検索が困難になります。 最も簡単なものから始める価値がありますが、必要なものより少し多いか少し少ないものを見つけることができます。 キーワードまたは分類子を使用してソースを検索することもできます。 ユーザーアクションによって呼び出されるエラーと機能を検索するための特別な手法があります。

コードの理解

コード検索は、その理解と密接に関連しています。 検索中に得られた結果の修正方法と使用方法を理解するために、問題を解決するのに本当に役立つ発見されたすべてのソースブロックから選択するためには、理解が必要です。

コードを読まずに理解する

コードベースの外部では、コードの検索が開始されるだけでなく、それを理解するプロセスも開始されます。 アプリケーションの実行、ドキュメントの読み取り、バグトラッカー、アプリケーションログまたはバージョン管理システム、チームおよび（または）ユーザーとの通信により、アプリケーション内で何が起こっているかを把握できます。 ソースを検索するときと同様に、コードを直接読み取る前に、分析対象の領域についてすでにわかっていることを覚えておくことが重要です。

ブラックボックスリーディング

コードを「ブラックボックス」として読むことは、外部の兆候によって、関数またはクラス内で何が起こっているかを確立しようとしていることを示唆しています。 オブジェクトの名前、受け入れられるパラメーター、および戻り値を見ることで、オブジェクトの目的を推測できます。 例えば

public ResultOrError SetToClipboard(Image image)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ほとんどの場合、画像イメージをクリップボードに配置し、返されたResultOrErrorで発生したエラーに関する情報を配置します。



「ブラックボックス」を読むには、命名規則、つまり、プレフィックス、ポストフィックス、およびプロジェクトで受け入れられる名前の他の部分について知ることが重要です。 「ブラックボックス」とは、関数内の説明やコメントを読むことを指します。



関数の目的に関する仮定が正しいことを確認するために、その使用法を調べることができます。 また、関数呼び出しにつながるユーザーアクション（たとえば、ユーザーが[クリップボードにコピー]ボタンをクリックした）を見つけ、この知識に基づいて、関数の結果としてユーザーが受け取るものを理解します（この場合、明らかに、クリップボード）。



ReSharperには、関数の呼び出し元の場所を見つけることができる強力なInspect ThisツールとFind Usagesツールがあります。 検査これは、関数が呼び出される場所などが呼び出されるコードフラグメントを簡単かつ明確にさらに検索できるため、より便利なようです。 Visual Studio自体では、[階層の呼び出し]ツールをすぐに使用できます。このツールには、[Inspect This]と同様の機能があります。





関数が使用される場所（ShareX.UploadManager.UploadFile：66-80）

• Inspect This（左）;
• 用途を検索（中央）;
• 呼び出し階層（右）。

ホワイトボックスを読む

「ブラックボックス」内でメソッドコードが「閉じられた」場合（境界および関数周辺のソースを調査する場合）、「ホワイトボックス」では調査中のメソッド内のコードを調査することになります。



「ホワイトボックス」では、ソースコードの読み取り順序が重要です。 一方では、コードを理解するために、コード全体を読む必要はありません。したがって、重要性の低い行をスキップして、コードの最も重要な部分から読み始める必要があります。 一方、理解の速度は読みの順序に依存します。 左から右、上から下へ読むことは、ソースに飛び込む最良の方法ではありません。



「ホワイトボックス」を読み取る方法の1つは、「詳細」を読み取ることです。最初に第1レベルのコードを読み取り、次にレベルを2番目に進みます。





ディープリーディング（ShareX.UploadManager.UploadFile：43-64）



Visual Studioの場合、 C＃アウトラインアドオンがあり、if、for、およびその他の制御構造内のテキストを折りたたんだり展開したりできます（Visual Studioは、名前空間、クラス、領域、メソッドを折りたたんで展開できますが、if、forなどはできません）建設）。



「ホワイトボックス」としてコードを読み取るもう1つの方法は、「キープレースから」を読み取ることです。 原則として、これらは関数が結果を返したり計算したり、何らかの方法で入力パラメーターを使用したり、ファイル、画面、または他のデバイスに出力したりする場所です。 異なる機能の重要な場所は異なる場合があります。 最初にそれらを見つけて読むことができることが重要です。



Visual Studioには、選択されたキーワードの出現箇所が見つかったすべての場所をエディターおよびスクロールバーで強調表示するRockMarginアドオンがあります。 たとえば、taskSettingsをダブルクリックすると、RockMarginはファイル内でtaskSettingsが見つかったすべての場所を強調表示します。





ShareX \ UploadManager.csのRockMarginバックライト



アプリケーションには、多くの場合、類似したテンプレートが多数あります。 一般的に使用されるテンプレート（シングルトンなど）、またはプロジェクト固有のテンプレート（UI構築の一部の機能など）のいずれかです。 2つまたは3つのキーワードによってテンプレートの機能を理解できるため、「文字を解析する」ことなく「完全に」テンプレートを読む方法を学ぶ必要があります。 たとえば、下の図-シングルトンクラス。赤で強調表示されている2行のコードから推測できます。





クラスシングルトン（Greenshot.Drawing.Fields.Binding.DecimalFloatConverter：29-52）



ソースコードを読むときに従うべき別のシーケンスは、単純なものから複雑なものまでを読むことです。 まず、何が明確であるかを理解してから、より複雑な設計に進みます。



「ホワイトボックス」のセクションの終わりに、コードをレビューするときに読むことについて、いくつかの言葉を述べたいと思います。 直接読む前に（特にボリュームリビジョンを確認している場合）、変更されたすべてのファイルの名前を確認し、重要な変更が発生したファイルを理解する必要があります。 読み取りは、重要な変更を含むファイルから開始する必要があります。このファイルから、一般的な本質を把握し、他のすべての改善点をよりよく理解します。

コード改善

ソースコードを理解するには、それを読むだけでなく、改善することもできます。 コードの認識を改善する最も簡単な方法は、正しくインデントすることです。 読みやすさを改善する別の方法は、リファクタリングです。 最も単純な長い関数の名前変更といくつかの短い関数への分割により、プログラムのテキストをより理解しやすくすることができます。



複雑な論理構造を理解するために、ドモーガンの法則を適用できます。

 !(a && b) = (!a) || (!b) !(a || b) = (!a) && (!b)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードを改善するためのツールとして、ReSharperをお勧めします。ReSharperはさまざまな複雑さの改善に対応します。

デバッグモード

デバッグモードでは、ソースコードの読み取り中に行われた仮定を確認できます。 デバッグモードでの読み取りには、ブレークポイントなどのツールの使用が含まれます（たとえば、特定の変数値でのみトリガーされる「条件による」ブレークポイントを含む）、スタックトレースの表示、プログラムのステップごとの実行、変数の値の表示と変更。

全体像

読むときは、分解されるモジュールで何が起こっているかについての一般的な考え方を維持し、「パズル」のさまざまな場所をすばやく移動できることが重要です。



全体像を念頭に置くために、プロジェクトに存在する図と新しい図の両方を使用できます。 特にSQLクエリの場合、一部のチャートは自動的に作成できます。 たとえば、PL / SQL Developerには、クエリに関係するテーブルとその関係を示すクエリビルダがあります。 たとえば、Visual Studioでは、クラス図の表示ツールを使用してクラス図を自動的に作成できます。 ただし、多くの場合、手描きの図でも十分です。



ReSharper、Inspect This、またはVisual Studio Viewに組み込まれているCall Hierarchyツールを使用して、呼び出されたメソッドを読むと便利です。 「ブラックボックス」のセクションでは、これらのツールは既に検討されていますが、関数が呼び出された場所が調査されました。 ここでは、関数内で呼び出されるメソッドの表示について説明しています。 これを検査し、コール階層を表示すると、コールツリー全体が表示される完全な画像が表示され、すばやく移動できます。



コードの任意のブロックをすばやくジャンプするには、タブを固定し（作業中に開く必要があった他の20から100と、密接に作業する5から10のクラスを区別するため）、エディターをブックマークするか、手動で書き込みます。クラスとそのメンバーの名前を書きます。



ファイル内のクイックトランジションには、ReSharper-ファイル構造（現在のクラスのメンバーを表示）、Visual Studio-メンバー（ファイル構造に類似）またはRockMargin （縮小されたソースコードを幅の広いスクロールバー、色合いのブックマーク、ブレークポイントに表示）で便利です。

まとめ

ソースコードを直接読む前に、コードベース以外のさまざまなソースに目を向けることが重要です。チームと通信し、ドキュメントを読み、実行のためにアプリケーションを実行します。 これにより、アプリケーションの基本的な理解が得られ、コードを直接読むことができます。 ソースコードを「ブラックボックス」として読み取り、メソッドの名前、受け入れられるパラメーターなどを「ホワイトボックス」として分析し、メソッド内の内容を分析できます。 コードの認識を容易にするために、たとえばインデントを改善できます。 アプリケーションを実行すると、デバッグモードで行われた仮定を検証できます。 最後に、本を読むときは、頭の中で全体像を保ち、調査中のモジュールのさまざまな部分をすばやく移動できることが重要です。

おわりに

コードを見つけて理解することは、ソフトウェア製品を扱う上で重要なステップです。 検索と理解は、リポジトリの外部から始まります。チームと通信し、ドキュメント、バグトラッカーを読んで、実行のためにアプリケーションを起動します。 検索と理解は、既存のモジュールを完成させるとき（既存のモジュールを完成させるために、それがどのように機能するかを理解する必要があります）と、新しい機能を開発するときに必要です：はい、新しいモジュールはコードを1行も読まずに開発できますが、プロジェクトでは、同様の機能を実装する個別のブロックがあり、関数とクラスの実装のテンプレートとして使用できます。



私の意見では、広義のコード（つまり、ソースの検索と理解の両方）でのコードの読み取りは、開発者がタスクの作業の別の段階に割り当てる必要があります。 この段階の結果は、特定のコードブロックの作業の一般的なアイデアだけでなく、タスクで作業するときに役立つメソッドとファイルのブックマークのセットです。 直接プログラミングのフレームワークで既に、ソースの検索を継続する必要があります。 たとえば、次のように、新しいクラスに出会い、使用されている場所を見つけ、便利なブックマークのリストを更新しました。 おそらく、チーム内の別の機能でブックマークの選択を区別できます。技術リーダーまたは担当の開発者が有用なブックマークのリストを作成し、その後、プログラマーが仕事に取りかかります。



ソースの検索と理解の両方のために、名前の規則とクラス（フォルダー、名前空間）を整理する方法を知ることが重要です。 著者の経験によると、このような理解はプロジェクトの作業中に得られますが、コードデザインに関する合意（コードスタイルガイド）と同じ方法で、合意を正式なものにして新しい開発者に伝えることができます。

クラスの順序の名前と方法に関する実際の既存の合意を明らかにする自動化ツールを開発することは有望なようです。 最も一般的なフォルダ名、接尾辞、接尾辞などを識別するツールが役立つようです。



コードを読むとき、および通常の本を読むときは、読む目的を理解し、念頭に置くことが重要です。 コードを読むために、プレーンテキストの読み方に関する記事からいくつかのトリックを適用できます（たとえば、 「読んだテキストを理解する能力を向上させる方法？」を参照）。



評価できる限り、コードの検索と理解は、国内外の文献ではあまり触れられていないトピックです。 提示された記事が、コードベースを使用した効果的な作業のテクニックを習得するのに役立つことを願っています。