デバッグは楽しいです。なぜなら、それは謎で始まるからです。あなたは何かをすべきだと思うが、代わりに何かをする。それはいつも非常に簡単なわけではありません---私が与えることができる例は、実際に時々起こるものと比較して考案されます。デバッグには創造性と創意工夫が必要です。デバッグする単一のキーがある場合は、ミステリーで分割と征服のテクニックを使用することです。
たとえば、シーケンスで10個を実行するプログラムを作成したとします。あなたがそれを実行すると、クラッシュします。あなたがクラッシュするようにプログラムしていないので、今あなたは謎を持っています。出力を見ると、シーケンスの最初の7つが正常に実行されたことがわかります。最後の3つは出力から見えないので、今はあなたの謎は小さくなります： 'それは＃8、＃9、または＃10の物に墜落しました。
どのようなものがクラッシュしたかを確認するために実験を設計できますか？確かに。 ＃8と＃9の後に、デバッガを使用することもできますし、printline文（またはあなたが作業している言語に相当するもの）を追加することもできます。私たちがもう一度それを実行すると、「それは事9番に墜落しました」というような私の謎は小さくなるでしょう。いくつかの人々が問題に圧力をかけて一緒に働いているとき、最も重要な謎が何であるかを忘れるのは簡単です。
デバッグ技術として分割して克服する鍵は、アルゴリズム設計と同じです。ミステリーを途中で分割すると、何度も分割する必要はなくなります。迅速にデバッグすることができます。しかし、謎の真ん中は何ですか？これは、真の創造性と経験が生まれる場所です。
真の初心者にとって、考えられるすべてのエラーの領域は、ソースコード内のすべての行のように見えます。実行された行のスペース、データ構造、メモリ管理、外部コードとのやりとり、危険なコードなど、プログラムの他の次元を見るために後で開発するビジョンはありません。単純なコードです。経験豊富なプログラマーにとって、これらの他の次元は、間違っている可能性があるすべての事柄の不完全だが非常に有用な精神モデルを形成する。その精神モデルを持つことは、謎の真ん中を効果的に見つけるのに役立ちます。
間違っている可能性のある領域を均等に細分したら、エラーがどの領域にあるかを判断する必要があります。私のプログラムがクラッシュする単一の不明な行はどれですか？単純なケースでは、自分が実行しているプログラムの途中で実行されると判断した行の前または後に未知の行が実行されていますか？ '通常、エラーが単一の行に存在するか、単一のブロックであるかを知ることは大変幸運なことではありません。しばしば、ミステリーは、「間違ったノードを指し示すポインタがそのグラフにあるか、またはそのグラフ内の変数を加算するアルゴリズムが機能しません」という場合があります。その場合は、分割された謎のどの部分を除去できるかを決定するために、グラフ内のポインタがすべて正しいことを確認する小さなプログラム。 Next How to Remove an Error