特定の機能を実装したソースコードを見つける方法 [閉まっている]

デスクトップアプリケーションで、どのコードが特定の機能を実装しているかを特定するためのテクニックは何だろうと思っていました。

私はジュニア開発者であり、ウェブプログラミングを中心にプロのプログラミング経験しかありません。Webでは、これを行うのが簡単です。たとえば、ブラウザツールでボタンを「検査」し、クリックすると何が行われているかを確認できます。そして、完全なソースコードがあると仮定して、呼び出しの階層をドリルダウンできます。

しかし、デスクトップアプリケーションでこれをどのように行うのでしょうか？少なくとも、完全なコードベースに飛び込む必要はありませんか？

バックトレース

バックトレースは、機能に関連付けられたイベントへのエンドポイントの位置を特定します（以下を参照）。そこに、ブレークポイントがデバッガーに配置されます。この機能は、デバッガーが停止したときにトリガーされます。呼び出しスタックは、呼び出しパスを追跡するためにレビューされます。コールスタックを上に移動しながら、変数の状態をメモしたり、新しいブレークポイントを配置してイベントを再度検査したりできます。

この機能は再びトリガーされ、デバッガーは新しいブレークポイントで停止します。その後、目標が見つかるまで、バックトレースを繰り返すか、フォワードトレースを実行できます。

長所短所

• コールスタックを上に移動して、どこに到達したかを確認する方が常に簡単です。
• エンドポイントに到達する前に、真である必要がある数百万の条件が存在する可能性があります。エンドポイントが既にわかっている場合、多くの作業を節約できます。
• 機能が壊れている場合。エンドポイントに到達できない可能性があり、その理由を突き止めるために時間を浪費する可能性があります。

エンドポイント検出

機能をデバッグするには、ソースコードのどこで最終目標が達成されているかを知る必要があります。この時点からのみ、バックトレースしてコードがそこに到達した方法を確認できます。例; 元に戻す方法を理解するため。コードのどこで元に戻すかは知っていますが、どうやってそこにたどり着くのかわかりません。これは、機能がどのように機能するかを把握するためのバックトレースの候補になります。

前方トレース

フォワードトレースは、機能に関連付けられたイベントの開始点を特定します（以下を参照）。ロギングメッセージがソースコードに挿入されるか、ブレークポイントが設定されます。このプロセスは、機能の目標が見つかるまで開始点からさらに進むにつれて繰り返されます。

長所短所

• 機能を見つけるための最も簡単な出発点です。
• コードが複雑になると、フォワードトレースの効果が低下します。コード内の条件が多いほど、間違った方向に進む可能性が高くなります。
• 前方トレースでは、多くの場合、無関係なイベントによってトリガーされるブレークポイントが設定されます。デバッグプロセスを中断し、検索を妨害します。

スタートポイントディスカバリー

キーワード、ユーザーインターフェイス識別子（ボタンID、ウィンドウ名）、または機能に関連付けられた簡単に見つけられるイベントリスナーを使用できます。たとえば、元に戻す機能をトリガーするために使用するボタンから始めることができます。

消去のプロセス

これは、開始点と終了点の位置と比較した中間点と考えることができます。機能でコードの一部が使用されていることがわかっているが、それが機能の開始でも終了でもない場合は、削除プロセスを実行します。

中間点から進む方向は、入口と出口の数によって異なります。コードチャンクが多くの場所で使用されている場合、この位置からのバックトレースはすべて検査する必要があるため、非常に時間がかかる可能性があります。次に、削除プロセスを使用して、このリストを減らします。別の方法として、この時点から前方トレースを実行することもできますが、コードチャンクが多くの場所に分岐する場合も、これが問題になる可能性があります。

フィーチャに対して明らかに実行されないパスをたどらないことで、位置の方向を減らす必要があります。このコードを過ぎて、機能に関連する可能性が高い場所にのみブレークポイントを配置します。

多くの場合、中間点のデバッグには、より高度なIDE機能が必要です。コード階層と依存関係を表示する機能。これらのツールがなければ、実行するのは困難です。

長所短所

• 多くの場合、中間点は、この機能を考えるときに頭に浮かぶコードの最初の部分です。あなたは自分自身に「ああ、それは働くためにXXXXを使わなければならない」と言います。
• 中間点は、開始点を最も簡単に明らかにすることができます。
• 中間点は、同期またはスレッドの変更によって失われた機能への軌跡を簡単に取得する方法です。
• ミドルポイントを使用すると、慣れていないコードにアクセスできます。何が起こっているかを学ぶのに時間をかけます。

この機能がボタンやメニューなどのUIのものに結び付けられていると仮定すると、私がやる傾向があります（非常に退屈ですが動作します）。これは、デバッガーを使用せずに、ソースコードを調べています。

1. 「スーパーフィーチャーX3」など、ボタン上のテキストを検索します（できれば独特です）。
2. これはおそらく、いくつかの定数を持つファイルにあります SUPER_BUTTON_3 = "Super Feature X3"。後で参照できるように、このファイル名を覚えておいてください。
3. 抽象化の別の層（2つも）がある場合があります。ボタンで使用される「実際の」文字列を取得するために検索を続けます。これが将来どのように行われるかに注意してください。
4. 次に、その定数を検索します。うまくいけば、これでButtonが見つかりました。たぶん、そこがActionListenerを接続する場所です。（ここではYMMVのJava-eseを使用していますが、その概念はまだ保持されています）
5. 必要に応じて、そのボタンを検索すると、最終的にリスナーに接続される場所を見つけることができます。
6. おそらく、そのリスナーは定数に基づいて実際に他のリスナー（「実際の」機能）にリダイレクトし、そうであれば、if / elseまたはcaseステートメントに従います。 注：中央のディスパッチが多い場合は、ブレークポイントを設定するのに最適な場所です。
7. 最後に、実際のコードを確認する必要があります。

@amonが指摘したように、デバッガーの方が簡単な場合があります...

• 関連するコードをまったく見つけられる場合は、ソース管理ソフトウェアを使用して、コミット全体またはそれを追加した近くのコミットを表示できます。これにより、その機能を実装するために必要なすべてが表示されます。

• 見たい出発点を見つける簡単な方法の1つは、ボタンのテキストを探してコードベースをgrepすることです。

• 多くの場合、人々は自分のコミットメッセージに課題トラッカーから課題IDを入れます。機能リクエストを説明する問題を見つけることができる場合は、その問題IDのコミットを検索できます。