IDEなしでどのようにデバッグしますか？[閉まっている]

IDE（現在はGoをいじっています）を探すたびに、Vi、Emacs、Notepad ++などを推奨する人でいっぱいのスレッドが見つかります。

IDE以外で開発を行ったことはありません。私は甘やかされてきたと思います。IDEなしでどのようにデバッグしますか？ロギングのみに制限されていますか？

デバッガーを使用する。ほとんどの場合、これはIDEが舞台裏で行うことでもあり、GUIでエクスペリエンスをラップするだけです。

Unixでは、最も一般的に使用されるデバッガーの1つはGNUですgdb。これは、などの初期のUnixデバッガーに大きく取って代わりましたdbx。

コマンドラインからデバッグがどのように/どのように感じられるかを知るには、gdbのマニュアルをご覧ください。

他の領域と同様に、コマンドラインからデバッガーを使用するには、構文と一連のコマンドを学習する必要がありますが、多くの柔軟性とスクリプト可能性をもたらします。一方、vimやemacsなどのエディターでの作業に慣れている場合は、お気に入りのエディターにお気に入りのデバッガー用のプラグインがあることがわかります。

グラフィックドライバーを書いている間、私は数年間デバッガーを使用しました。最初のコンピューターに対してデバッガーを実行する2番目のコンピューターがありました（グラフィックスドライバーが壊れたときにプライマリコンピューターの画面が機能しないため）。コードを停止し、ハードウェアを停止するまで踏み込んで、何が起きているのかを知ることが重要でした。

純粋にソフトウェアの問題については、コードを1行ずつステップ実行するよりも、問題について考え、システムをテストして問題の詳細を調べる方がはるかに便利であることがわかりました。printステートメントを使用すると、コマンドラインまたはログファイルで発生したすべてのリストが表示され、デバッガーを使用した場合よりも簡単に前後に移動して、発生した内容を確認および再構築できます。

最も難しいバグは通常、コンピューターから離れたところで問題を理解することで解決されます。ときどき紙やホワイトボードを使ったり、何かをしているときに答えが明らかになることもあります。最も厄介なバグは、Where's Waldoのようなコードを注意深く見ることで解決されます。残りはすべて、printステートメントまたはロギングステートメントを使用すると最も簡単に思えます。

人によってスタイルが異なり、タスクごとにスタイルが異なる方が適しています。印刷ステートメントは、必ずしもデバッガーからのステップダウンではありません。あなたが何をしているのかにもよりますが、彼らはさらに良くなることができます。特に、ネイティブデバッガーがない言語（Goを使用しますか？）。

コマンドラインでgdbまたはプラグインを使用する人もいます。DDDのような、gdbへのスタンドアロンGUIフロントエンドもあります。お使いの言語に応じて、言語固有のスタンドアロンデバッガなどのGUIの、あるWinpdbのpythonのため、またはjswat Java用に。これらのプロジェクトはデバッグのみに焦点を当てているため、多くの場合、統合デバッガよりも優れています。

IDEに関する他の汚い小さな秘密は、それらすべてがカスタムエディターを指定できるので、IDEの一部を特定のタスクに使用できますが、編集には適切なエディターを使用できることです。IDEを起動してデバッガーを使用することは珍しいことではありません。特に同僚が使用している場合はそうです。

一部の言語ではREPLが提供されます。つまり、コードを1行ずつ記述して実行することができます。これは、コードの検証の最初のステップになります。これらの多くは、デバッグ機能も提供します。HaskellのGHCにはGHCiが付属しており、IDEの場合と同様に、コマンドラインでプログラムをインタラクティブにデバッグするために使用できます。

printfステートメントを使用したデバッグに嫌悪感がある理由がわかりません。プログラムの再コンパイルとリンクに時間がかかりすぎていた時期がありましたが、今日ではほんの数秒しかかかりません。cout、printf、qDebug（）などのタイプの出力を使用してデバッグするのは非常に簡単です。Printfステートメントは、プログラムが実行したすべての実行履歴を提供します。これは事後に分析できますが、デバッガーで実行すると、実行中のプログラムのフローを手動で記憶する必要があります。printfを使用すると、変数の値を特定の単位に変換し、16進数、10進数などで表示できます。printfステートメントは、ルーチンと変数の名前、および行番号もリストできます。他の変数に応じて、特定の配列要素のみをリストできます。インダイレクションに従うことができます。出力を非常に簡単に制御できますが、カウンターに入れて、ループで特定の時間だけ印刷し、デバッグ中に印刷ステートメントを追加および削除し、さまざまなレベルのデバッグ出力を持ち、ファイルに書き込みます。ファイルに書き込まれたプログラムの履歴を見るのは、手動でステップスルーしたすべての場所を覚えてみてください。また、プログラムが何をしたかを知るために、変数の内容を時間の経過とともに書き留める必要があります。そして最後に、printfステートメントを使用すると、それらを永続的に残して、オンとオフを切り替えて、将来のデバッグに使用できます。手動でステップスルーしたすべての場所を記憶しようとするよりも、ファイルに書き込まれたプログラムの履歴を確認する方がはるかに簡単です。完了しました。そして最後に、printfステートメントを使用すると、それらを永続的に残して、オンとオフを切り替えて、将来のデバッグに使用できます。手動でステップスルーしたすべての場所を記憶しようとするよりも、ファイルに書き込まれたプログラムの履歴を確認する方がはるかに簡単です。完了しました。そして最後に、printfステートメントを使用すると、それらを永続的に残して、オンとオフを切り替えて、将来のデバッグに使用できます。

jimwiseはこの質問に非常によく答えましたが、完全なIDEなしで作業することを選択した場合、Microsoftが提供するWindows用のコマンドラインデバッガーはCDBと呼ばれます。CDBには、Windows SDKをダウンロードするときに、GUIに相当するWinDBGなど、他のいくつかのツールが付属しています。

私は通常、デバッガを使用しません。おそらく数週間に1回ですが、最初に行くものではありません。

私の仕事で最も重要なツールはどこにでもあるので、言及するのをほとんど忘れていました。スタックトレースです。スタックトレースを調べることで、遭遇する問題の90％以上を解決できます。このツールは、言語によっては必ずしも役立つとは限りませんが、言語によって適切に実装されている場合、驚くほどの時間を節約できます。

単純な問題を検出する2番目の最も一般的な方法は、おそらく変更したばかりのコードだと思います。私はユニットテストを非常に頻繁に実行しているので、私は一般に私がちょうど壊したことを知っています。

より複雑な開発とデバッグのために、デバッグまたはトレースレベルのログステートメントを追加する場合があります。開発の問題は、実稼働トレース/デバッグロギング情報を配置するのに役立つ良いガイドであると考えています。

常に便利なデバッガーがあるわけではありません。実稼働環境では、デバッガーを実行できない場合があります（たとえば、会社の安全性によっては、ログ以外の実稼働マシンにアクセスできない場合があります）。また、デバッガーの接続に時間がかかりすぎる言語や、使用可能な良いデバッガーがない言語もあります。

ロジックとデバッグ/トレースレベルのログを使用してずっとコーディングしてきた場合は、単に優れたログステートメントを調べて（場合によってはログレベルを上げて）、ハードウェアにアクセスしなくても問題を把握することができます。

デバッガは強力なツールだと思いますが、ツールボックス内の唯一のツールにしないでください！

スタンドアロンのテキストエディターと一緒にIDEでデバッガーを使用できない理由はありません。私は、！Zapを使用して編集し、JBuilderを使用して別のマシンでデバッグし、地下のファイルサーバーを使用していました。従来、デバッガはIDEに沿ってドラッグすることのないスタンドアロンプ​​ログラムでしたが、これも機能します。

包括的なテストがデバッグに取って代わることに注意してください。報告されたバグは、コードではなくテストのバグであると考える価値があります。

もありprintfます。すべての行で停止するのではなく、大量の「ログ」を作成して検索すると便利です。実稼働環境では変更できないライブラリクラスを変更できる場合、たとえば-Xbootclasspath/p:Javaライブラリクラスのハッキングに使用すると、特に便利です。

ペンと紙を使って、または単に問題について考えるだけで、コンピューターから離れて最高の問題を解決できることに同意します。これは、ライブデバッガーを使用するよりも便利です。多くの場合、思考プロセスを修正します。

シンプルなユーザーインターフェイスを備えたコンソールであるpudbを使用できます。REPLを入力して詳細を調べる場合は、pdbやipdbなどの好みのデバッガーを選択できます。

また、利用可能なツールのより包括的なコレクションについては、PythonDebuggingTools Wiki を確認してください。