9

プログラミングの学生としての私の最大の弱点は、他の人のコードを理解する能力が低いことだと気づきました。

「教科書」のコードや明確にコメントされたコードは何の問題もありませんが、数十行のプログラムがあり、数十の異なる関数が含まれ、コメントがない場合、開始することすら非常に困難です。

この種のコードは、私のキャリアで遭遇する可能性が高いと思います。コードの理解力が低いと、大きな障害になると思います。そのため、スキルの向上に注力したいと思います。このエリアの中では。

どのようなツール/テクニックがあなたの経験におけるコード理解を改善するのを助けましたか?

なじみのない、コメントのないコードにどのように取り組む傾向がありますか?なんで?あなたのテクニックはどうですか?

ありがとう

4

5 に答える 5

4

外部コードに慣れる

コードベースが十分に小さければ、すぐに読み始めることができます。ある時点で、破片が一緒に落ち始めます。

このシナリオでは、「十分に小さい」はさまざまで、経験が増えるにつれて大きくなります。また、ここで「不正行為」の恩恵も受け始めます。経験から「パターン X の実装」として認識しているコードの断片をスキップできます。

コードを読んでいる間、ちょっとした回り道をするのが役に立つかもしれません。例えば、関数が呼び出されているのを見て、それをざっと見てみるなどです。呼び出された関数が何をするかを理解するまで、これらの回り道にとどまらないでください。これはポイントではなく、飛び跳ねて進歩していないように感じます。迂回するときの目標は、新しい機能が何をするのかを 30 分以内に理解することです。できない場合は、機能が複雑すぎることを意味します。回り道をやめて、この余分な助けなしに「現在の」機能を理解する必要があるという事実を受け入れてください。

コードベースが大きすぎると、すぐに読み始めることができません。この場合、高レベルの抽象化でプログラムの論理コンポーネントを識別することから始めることができます。目標は、ソース コード内の型 (クラス) をこれらのコンポーネントに関連付けてから、各クラスがそのコンポーネントで果たす役割を特定することです。コンポーネント内で使用されるクラスと、他のコンポーネントまたはフレームワークとの通信に使用されるクラスがあります。ここで分割して征服します。まずクラスを関連するグループに分割し、次にグループに注目して、その部分がどのように組み合わされるかを理解します。

この作業を支援するために、ソース コードの構造をガイドとして使用できます (究極の法則としてではなく、人的ミスにより誤解を招く場合があります)。関数や型の「使用箇所の検索」などのツールを使用して、それぞれがどこで参照されているかを確認することもできます。繰り返しになりますが、合理的に迅速に実行できない場合は、IDE が指示する内容を完全に消化しようとしないでください。これが起こるとき、それはあなたが完全に理解していない機械から複雑な金属片を選んだことを意味します. 理解できるものが見つかるまで、元に戻して別のことを試してください。

外部コードのデバッグ

これはまったく別の問題です。私は少しごまかしますが、大量の経験を積むまでは、コードが自分にとってなじみのないものである限り、コードのデバッグを成功させる方法はありません。

于 2010-12-02T15:12:27.573 に答える
2

コールグラフと継承ツリーを描画すると、うまくいくことがよくあります。手元にある任意のツールを使用できます。私は通常、ホワイトボードを使用します。

通常、コード単位/機能はそれ自体で理解するのに十分簡単で、各単位がどのように動作するかを明確に理解できますが、全体像を理解するのに苦労することが多く、そこで故障が発生し、「私は」迷子」な感じ。

小さく始めましょう。「 xを達成したいのですが、コードでどのように実行されますか?」と自問してください。ここで、xはトレースできる小さな操作です。次に、コードをトレースして、トレース後に振り返ることができる視覚的なものを作成します。

次に、別のxを選択してプロセスを繰り返します。これを行うたびに、コードの感触が良くなるはずです。

何かを実装するときが来たら、トレースしたものの 1 つに似ている (ただし、ほとんど同じではない) ものを選択します。これにより、トレース レベルの理解から実装レベルの理解に移行します。

初めてコードを書いた人と話すことも役に立ちます。

于 2010-12-02T15:01:49.090 に答える
2

私が最初に試みることは、コードの目的が何であるかを大まかに把握することです。詳細は、問題のドメインについて少し理解するまでは関係ありません。それを理解する良い方法には、識別子の名前を調べることも含まれますが、通常は、コンテキストを考慮する方がさらに役立ちます。このコードはどこから入手したのでしょうか? 誰が書いたの?既知の目的を持つアプリケーションの一部でしたか? コードが何をすべきかを理解したら、コピーを作成し、個人的に理解しやすいように再フォーマットを開始できます。これには、必要に応じて識別子の名前を変更したり、奇妙なインデントを整理したり、空白を追加して物事を分割したり、それらが何をするかを理解したらビットをコメントしたりすることが含まれます。とにかく、それが始まりです... :)

また、コードの目的を理解したら、いくつかの簡単な例でデバッガーを実行すると、FWIW で何が起こっているかをより明確に理解できる場合があります...

于 2010-12-02T15:03:59.560 に答える
1

ご不満はお察ししますが、世の中には悪いコードがたくさんあることを心に留めておいてください。すべてのコードが悪いわけではありません:)

これは私が従う傾向があるプロセスです:

  1. コードが何をすべきかを文書化する必要があるため、単体テストを探してください...
  2. Code rush / resharper / Visual Studio のショートカットを使用してコードをナビゲートします。これにより、関連する論理層と物理層についていくつかのアイデアが得られるはずです...
  3. 最初にコードをスキャンし、一般的なパターン、命名規則、およびコード スタイルを探します。これにより、チームの標準と、元のコーダーの考え方についての洞察が得られるはずです...
  4. コード階層をナビゲートしながら、使用されているオブジェクトをメモします...通常はペンと紙で簡単なアクティビティ図を描きます:
  5. 私は共通のエントリ ポイントから開始する傾向があるため、UI の場合はビューから開始してデータ アクセス コードまで進み、サービスの場合はサービス境界から開始してデータ アクセスまで進みます。コード...
  6. リファクタリングできるコードを探してください - リファクタリングできるコードが見つかれば、動作を変更せずに単純化する方法を学習したことになります...
  7. レビューしているのと同じものを構築する練習をしますが、別の方法で...
  8. テストされていないコードを読みながら、テスト可能にする方法を考えてください...
  9. コード ラッシュ診断ツールを使用して、メンテナンスの複雑性または循環的複雑性が高いメソッドを見つけ、これらの領域に特別な注意を払います。可能性があるため、これが最も多くのバグがある場所です...

幸運を

于 2010-12-02T15:30:31.883 に答える
0

理解は素晴らしいコード分析ツールです。以前の雇用主(L-3)で広く使われていたので、現在働いている場所で購入しました。

于 2010-12-02T15:12:47.383 に答える