4

他の人のソース コードを読んだ場合、そのコードにどのようにアプローチしますか? どのようなパターンを探していますか (データ型、ループ、制御フローの使用など)? 他の人のコードを飽きずにどれくらい読めますか? これまでに発見した最もエキサイティングなパターンは何ですか?

4

6 に答える 6

8

最初は、コードを変更したいという衝動を無視します。これは時々難しいことです。しかし、最初に理解してから変更することで、厄介な「学習体験」を大幅に省くことができます。

次にフォーマットが悪い場合は、再フォーマットします。コード フォーマッタがある場合は、それを使用します。これはインデントに目が行きがちなためで、それが悪いとコードの理解にも疑問が残ります。

次に、複雑なデータ構造がある場合は、少し図を描くのが好きです。ここでの課題は、できるだけシンプルに保つことです。大きな図を壁に飾るのは楽しいものですが、ほとんどの場合、見るのが面倒です。だから時間の無駄です。

コードの一部が何をするのかを最終的に理解したら、コメントを書いてください。これは必須です。そうしないと、次回ここに来たときに理解できないからです。

次のステップは、単体テストを作成することです。コードをテストできるだけでなく、コードの理解度もテストできます。

最後に、それをすべて理解し、改善できる (そして改善する必要がある) ことがわかっている場合は、それを変更します。ただし、必ずテストを実行してください。解決されたバグごとに支払われない限り。

于 2008-11-20T12:38:02.863 に答える
3

これに対する最新の用語はCode Spelunkingです。

于 2008-11-20T12:41:56.570 に答える
1

明白な「トップダウンでの作業」の一般的なアプローチは別として、それは私がそれを読んでいる理由によって異なります:コードレビュー、自分の使用に適応するために利用可能なコードのビットを理解しようとする、新しい技術を学ぶことなど。 。

また、言語にも大きく依存します。それがOOPLの場合、私はおそらく次のようなことをします。

  1. 最初にプライマリクラスの関係を探し、各クラスの主な責任を理解してください。
  2. クラス間の相互作用を見て、それらがどのように連携するかを確認します。
  3. キークラスのインターフェースを見て、それらがコラボレーターに提供する「サービス」を確認します。
  4. それらが責任を負うものではなく、それらがどのように機能しているかを理解することが重要である場合は、重要な方法の内部を調べてください。
于 2008-11-20T13:12:55.883 に答える
1

ありがとう、私が正しく理解していれば、最初のステップはコンテキストを識別し、次に API を識別し、API をコンテキストに配置することです。建物や芸術作品を見るのと少し似ていると思います。使用されている素材や部品の機能に焦点を当て、さまざまな視点を試して、部品が全体にどのように適合するかを判断できます...素敵な作品があります発見のプロセス:ここ - 数学者の考え方

于 2008-11-20T12:37:41.163 に答える
0

それはすべて、読んでいるコードの種類によって異なります。それは Web アプリですか、サービスですか、それともデスクトップ アプリですか? 他の人のコードを読み始めるときは、通常、使用されているデザイン パターンを探し始めます。または、フレームワーク固有のものについて。ただし、これはレビューを行う場合です。あなたが自分自身の興味のために読んでいて、何かを学ぶために読んでいるのなら、本当に答えはありません - コードを完全に読んで理解する必要があります。

于 2008-11-20T12:23:41.003 に答える
0

最終製品で理解できるアイテムを選び、それがどのように組み立てられるかを確認します。単体テストがある場合は、非常に役立ちます。

于 2008-11-20T12:48:10.520 に答える