IDEなしでどのようにデバッグしますか？
IDE（現在、私はGoをいじくり回しています）を探すたびに、Vi、Emacs、Notepad ++などを推奨する人でいっぱいのスレッドを見つけます。
IDEの外部で開発を行ったことはありません。私は甘やかされてしまったと思います。 IDEなしでどのようにデバッグしますか？ロギングだけに制限されていますか？
デバッガーを使用する。ほとんどの場合、これはIDEが舞台裏で行うことでもあります-エクスペリエンスをGUIでラップするだけです。
Unixでは、最も一般的に使用されるデバッガーの1つはGNU gdbです。これは、dbxなどの以前のUnixデバッガーに代わるものです。
コマンドラインからデバッグがどのように/どのように感じられるかを理解するには、 gdb manual を参照してください。
他の領域と同様に、コマンドラインからデバッガーを使用するには、構文と一連のコマンドを学習する必要がありますが、lotの柔軟性とスクリプト機能を備えています。一方、vimやemacsなどのエディターでの作業に慣れている場合は、お気に入りのエディターにお気に入りのデバッガーのプラグインが含まれていることがあります。
グラフィックドライバを書いている間、私はデバッガを数年間使用していました。最初のコンピューターに対してデバッガーを実行する2番目のコンピューターがありました（グラフィックドライバーが壊れていると、プライマリコンピューターの画面が機能しなかったためです）。コードを停止して、ハードウェアを吊るすところまで踏み込んで、何が起こっているのかを知ることが重要でした。
純粋にソフトウェアの問題の場合、問題について考え、システムをテストして問題の詳細を確認する方が、コードを1行ずつ実行するよりもはるかに便利です。印刷ステートメントを使用すると、コマンドラインまたはログファイルで発生したすべてのリストが表示され、デバッガーを使用する場合よりも簡単に前後に進んで、何が起こったかを再構築できます。
最も難しいバグは通常、コンピューターから離れたところにある問題を理解することで解決されます。紙やホワイトボードを使用することもあれば、他のことをしているときに答えが明らかになることもあります。 Where's Waldoをプレイするようなコードを注意深く見ることにより、最も扱いにくいバグが解決されます。残りはすべて、印刷ステートメントまたはロギングステートメントで最も簡単に見えます。
人によってスタイルは異なり、タスクごとにスタイルも異なります。印刷ステートメントは、必ずしもデバッガーからのステップダウンではありません。あなたが何をしているのかに応じて、彼らはさらに良くなることができます。特にネイティブデバッガーがない言語では（Goはありますか？）.
コマンドラインで gdb を使用する人もいれば、 plugin を使用する人もいます。 [〜＃〜] ddd [〜＃〜] のようなgdbへのスタンドアロンGUIフロントエンドもあります。言語に応じて、Pythonの Winpdb やJavaの jswat など、言語固有のスタンドアロンデバッガGUIがあります。これらのプロジェクトはデバッグにのみに焦点を合わせているため、統合デバッガよりも優れていることがよくあります。
IDEに関する他の汚い小さな秘密は、それらすべてがカスタムエディターを指定できるようにする価値があるため、IDEの一部を特定のタスクに使用できますが、編集にはまともなエディターを使用できます。デバッガを使用するためにIDEのみを起動することは珍しいことではありません。同僚がすべて使用している場合は特にそうです。
一部の言語ではREPL-つまり、コードを記述しながら1行ずつ記述して実行できます。これは、コードの一部を検証するための最初のステップです。これらの多くは、デバッグ機能。HaskellのGHCにはGHCiが付属しており、IDEの場合と同様に、コマンドラインでプログラムを対話的にデバッグするために使用できます。
Printfステートメントを使用したデバッグが嫌いな理由がわかりません。プログラムの再コンパイルとリンクに時間がかかりすぎていた時期がありましたが、今日では数秒しかかかりません。 cout、printf、qDebug（）などのタイプの出力を使用してデバッグするのは非常に簡単です。 Printfステートメントは、プログラムが行ったすべての実行履歴を提供します。これは、事後に分析できますが、デバッガーで実行すると、プログラムの実行中にプログラムのフローを手動で覚える必要があります。 printfを使用すると、変数の値を特定の単位に変換し、16進数、10進数などで表示できます。 printfステートメントは、ルーチンと変数の名前、および行番号もリストできます。他の変数に応じて、特定の配列要素のみをリストできます。間接的にたどることができます。非常に簡単に出力を制御したり、カウンターを挿入したり、ループを介して特定の時間だけ印刷したり、デバッグ時に印刷ステートメントを追加および削除したり、さまざまなレベルのデバッグ出力を作成したり、ファイルに書き込んだりすることができます。プログラムは、手動でステップ実行したすべての場所を思い出そうとするのではなく、プログラムがファイルに書き込んだり、プログラムが行ったことを発見するために、時間とともに変化する変数の内容を書き留めたりする必要があります。そして最後に、printfステートメントを使用すると、将来のデバッグのために、それらを永続的に残して、オンとオフを切り替えることができます。
jimwise Answered 質問はかなりうまくいきますが、完全な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も確認してください。