[//]: # (Version:1.0.0)

デバッグはプログラマになるための基礎です。動詞 "debug"の最初の意味はエラーを取り除くことですが、実際に重要な意味は、プログラムの実行を調べて調べることです。効果的にデバッグできないプログラマーは目が見えません。

理想主義者、設計、分析、複雑さの理論などがデバッグよりも基本的だと考える人は、プログラマーを働かせていません。働くプログラマーは理想的な世界に住んでいません。あなたが完璧であっても、大手ソフトウェア会社、GNUのような組織、およびあなたの同僚によって書かれたコードに囲まれていなければなりません。このコードのほとんどは不完全であり、不完全に文書化されています。このコードの実行を可視化する機能がなければ、わずかなバンプはあなたを永遠に投げ捨てます。多くの場合、この可視性は実験（デバッグ）によってのみ得られます。

デバッグは、プログラムそのものではなく、プログラムの実行に関するものです。あなたが大手ソフトウェア会社から何かを購入した場合、通常はそのプログラムを見ることはできません。しかし、コードがドキュメントに準拠していない場所（マシン全体をクラッシュさせることは一般的で壮大な例です）やドキュメンテーションがミュートされている場所が発生します。より一般的には、エラーを作成し、書き込んだコードを調べ、エラーがどのように発生する可能性があるのか??わかりません。必然的に、これはあなたが作っているという前提がかなり正しくないこと、あるいはあなたが予期していない状態が発生したことを意味します。時には、ソースコードを眺めている魔法がうまく動作することもあります。そうでない場合は、デバッグする必要があります。

プログラムの実行を可視化するには、コードを実行してそのコードを観察できる必要があります。画面に表示されているもの、または2つのイベント間の遅延のように、これが目に見えることがあります。多くの場合、コード内のいくつかの変数の状態、実際に実行されているコードの行、または複雑なデータ構造にわたって特定のアサーションが保持されているかどうかなど、目に見えないものが含まれます。これらの隠されたものは明らかにされなければなりません。

実行プログラムの "nnards"を調べる一般的な方法は、次のように分類できます。

- デバッグツールを使用して、

- Printlining - プログラムを一時的に変更します。通常、情報を出力する行を追加します。

- ロギング - プログラムの実行に永続的なウィンドウをログの形で作成します。

デバッギングツールは、安定して利用可能な場合は素晴らしいですが、印刷ライティングとロギングはさらに重要です。デバッグツールは言語開発に遅れをとることが多いため、いつでも利用できない可能性があります。さらに、デバッグツールが微妙にプログラムの実行方法を変更する可能性があるため、必ずしも実際的ではない場合があります。最後に、大きなデータ構造に対するアサーションのチェック、コードの記述、プログラムの実行の変更など、いくつかの種類のデバッグがあります。デバッグツールが安定しているときにデバッグツールを使用する方法を知っておくことは良いことですが、他の2つの方法を使用できることが重要です。

いくつかの初心者は、コードを変更する必要があるときにデバッグを恐れています。これは理解できる - それは探索的手術のようなものです。しかし、あなたはコードを突き刺してジャンプさせることを学ばなければなりません。あなたはそれを試して、あなたが一時的に行うことはそれを悪化させるものは何もないことを理解することを学ばなければなりません。この恐怖を感じる場合は、メンターを探してください。この恐怖への敏感な始まりで、多くの優れたプログラマーを失います。

Next [How to Debug by Splitting the Problem Space](02-How to Debug by Splitting the Problem Space.md)

[//]: # (Version:1.0.0)

デバッグは楽しいです。なぜなら、それは謎で始まるからです。あなたは何かをすべきだと思うが、代わりに何かをする。それはいつも非常に簡単なわけではありません---私が与えることができる例は、実際に時々起こるものと比較して考案されます。デバッグには創造性と創意工夫が必要です。デバッグする単一のキーがある場合は、ミステリーで分割と征服のテクニックを使用することです。

たとえば、シーケンスで10個を実行するプログラムを作成したとします。あなたがそれを実行すると、クラッシュします。あなたがクラッシュするようにプログラムしていないので、今あなたは謎を持っています。出力を見ると、シーケンスの最初の7つが正常に実行されたことがわかります。最後の3つは出力から見えないので、今はあなたの謎は小さくなります： 'それは＃8、＃9、または＃10の物に墜落しました。

どのようなものがクラッシュしたかを確認するために実験を設計できますか？確かに。 ＃8と＃9の後に、デバッガを使用することもできますし、printline文（またはあなたが作業している言語に相当するもの）を追加することもできます。私たちがもう一度それを実行すると、「それは事9番に墜落しました」というような私の謎は小さくなるでしょう。いくつかの人々が問題に圧力をかけて一緒に働いているとき、最も重要な謎が何であるかを忘れるのは簡単です。

デバッグ技術として分割して克服する鍵は、アルゴリズム設計と同じです。ミステリーを途中で分割すると、何度も分割する必要はなくなります。迅速にデバッグすることができます。しかし、謎の真ん中は何ですか？これは、真の創造性と経験が生まれる場所です。

真の初心者にとって、考えられるすべてのエラーの領域は、ソースコード内のすべての行のように見えます。実行された行のスペース、データ構造、メモリ管理、外部コードとのやりとり、危険なコードなど、プログラムの他の次元を見るために後で開発するビジョンはありません。単純なコードです。経験豊富なプログラマーにとって、これらの他の次元は、間違っている可能性があるすべての事柄の不完全だが非常に有用な精神モデルを形成する。その精神モデルを持つことは、謎の真ん中を効果的に見つけるのに役立ちます。

間違っている可能性のある領域を均等に細分したら、エラーがどの領域にあるかを判断する必要があります。私のプログラムがクラッシュする単一の不明な行はどれですか？単純なケースでは、自分が実行しているプログラムの途中で実行されると判断した行の前または後に未知の行が実行されていますか？ '通常、エラーが単一の行に存在するか、単一のブロックであるかを知ることは大変幸運なことではありません。しばしば、ミステリーは、「間違ったノードを指し示すポインタがそのグラフにあるか、またはそのグラフ内の変数を加算するアルゴリズムが機能しません」という場合があります。その場合は、分割された謎のどの部分を除去できるかを決定するために、グラフ内のポインタがすべて正しいことを確認する小さなプログラム。

Next [How to Remove an Error](03-How to Remove an Error.md)

[//]: # (Version:1.0.0)

私は意図的にプログラムの実行をエラーを修正する行為から調べるという行為を分けた。もちろん、デバッグはバグを取り除くことを意味します。理想的には、コードを完全に理解し、エラーが完全に表示され、修正する方法を示す「ハハ！」の瞬間に到達します。しかし、あなたのプログラムでは、可視性のない文書化されたシステムを使用することが多いため、必ずしもそうであるとは限りません。他のケースでは、コードが複雑であるため、理解が完全ではありません。

バグを修正するには、バグを修正する最小限の変更を加えたいと考えています。あなたは改善が必要な他のものを見るかもしれません。同時にそれらを修正しないでください。一度に一つのこと、ただ一つの事を変える科学的方法を採用しようとする。このための最良のプロセスは、バグを簡単に再現し、修正プログラムを適用してからプログラムを再実行し、バグが存在しなくなったことを確認することです。もちろん、時には複数の行を変更する必要があるかもしれませんが、バグを修正するために概念的に1つのアトミックな変更を適用する必要があります。

時には、実際には1つのように見えるいくつかのバグがあります。バグを定義して一度に修正するのはあなた次第です。時々、プログラムが何をすべきか、または元の著者が意図したものが不明である。この場合、あなたは自分の経験と判断を行い、コードに自分の意味を割り当てる必要があります。何をすべきかを決定し、コメントしたり、何らかの方法でそれを明確にしたりして、コードをあなたの意味に適合させます。これは、最初の場所に元の関数を書くよりも時には難しい中級または上級のスキルですが、実際の世界はしばしば面倒です。書き換えができないシステムを修正する必要があるかもしれません。

Next [How to Debug Using a Log](04-How to Debug Using a Log.md)

[//]: # (Version:1.0.0)

*ロギング*は、ログと呼ばれる一連の有益なレコードを生成するようにシステムを作成する方法です。 * Printlining *は単純な、通常は一時的なログを生成しています。プログラミングの知識が限られているため、絶対初心者はログを理解して使用する必要があります。システム設計者は、システムの複雑さのためログを理解して使用する必要があります。ログによって提供される情報の量は、プログラムが実行されている間は理想的に構成可能でなければなりません。一般に、ログには3つの基本的な利点があります。

- ログは、再現するのが難しいバグ（プロダクション環境で発生するものの、テスト環境では再現できないバグなど）に関する有用な情報を提供します。

- ログは、ステートメント間の時間の経過など、パフォーマンスに関連する統計およびデータを提供できます。

- 構成可能な場合、ログは一般的な情報をキャプチャして、特定の問題を処理するためだけにコードを修正および/または再デプロイすることなく、予期しない特定の問題をデバッグすることができます。

ログに出力する量は、情報と簡潔さの間の妥協点です。情報が多すぎるとログが高価になり、*スクロールブラインド*が発生し、必要な情報を見つけることが難しくなります。情報が少なすぎ、必要な情報が含まれていない可能性があります。このため、出力を構成可能にすることは非常に便利です。通常、ログ内の各レコードは、ソースコード内の位置、実行可能な場合はそれを実行したスレッド、実行の正確な時刻、および一般的に、変数の値、データオブジェクトの数などが含まれます。これらのログステートメントは、ソースコード全体にわたって、特に主要機能点や危険なコードの周りに散在しています。各ステートメントにレベルを割り当てることができ、システムが現在そのレベルを出力するように設定されている場合にのみレコードを出力します。予想される問題に対処するために、ログステートメントを設計する必要があります。パフォーマンスを測定する必要性を予期します。

永続的なログがある場合は、ログレコードに関して印刷ラインを実行できるようになり、一部のデバッグ文がロギングシステムに永久に追加される可能性があります。

Next [How to Understand Performance Problems](05-How to Understand Performance Problems.md)

[//]: # (Version:1.0.0)

実行中のシステムのパフォーマンスを理解することは、デバッグを学習するのと同じ理由から避けられません。あなたが書いたコードのコストを完全に正確に理解していても、あなたのコードは、あなたがほとんど制御できないか可視である他のソフトウェアシステムを呼び出すでしょう。しかし、実際には、パフォーマンスの問題は一般的にデバッグよりも少し異なり、少し簡単です。

あなたやあなたの顧客が、システムやサブシステムの速度が遅すぎると考えているとします。速くしようとする前に、なぜそれが遅いのかの精神モデルを構築する必要があります。これを行うには、プロファイリングツールまたは適切なログを使用して、時間やその他のリソースが実際に費やされている場所を特定します。その時間の90％がコードの10％に費やされるという有名な言葉があります。私はそれにパフォーマンスの問題に対する入出力費用（I / O）の重要性を追加します。多くの場合、ほとんどの場合、I / Oはある意味で費やされます。高価なI / Oとコードの高価な10％を見つけることは、あなたのメンタルモデルを構築するための第一歩です。

コンピュータシステムの性能には多くの次元があり、多くのリソースが消費されます。測定する最初のリソースは、* wall-clock time *です。これは、計算に必要な合計時間です。ロギング*ウォールクロック時間*は、他のプロファイリングが実用的でない状況で起こる予測不可能な状況について通知できるため、特に重要です。しかし、これは必ずしも画像全体を表すとは限らない。場合によっては少し時間がかかりますが、実際に処理しなければならないコンピューティング環境では、非常に多くのプロセッサ秒を消費するものはずっと良いでしょう。同様に、メモリー、ネットワーク帯域幅、データベースまたは他のサーバーへのアクセスは、最終的にプロセッサ秒よりもはるかに高価になる可能性があります。

同期化された共有リソースの競合は、デッドロックと飢餓を引き起こす可能性があります。デッドロックは、不適切な同期やリソース要求のために処理できないことです。飢餓とは、コンポーネントを適切にスケジュールすることではありません。それがすべて期待できる場合は、プロジェクトの開始時からこの競合を測定する方法があることが最善です。この競合が起こらなくても、それを自信をもって表明できることは非常に有用です。

Next [How to Fix Performance Problems](06-How to Fix Performance Problems.md)

[//]: # (Version:1.0.0)

ほとんどのソフトウェアプロジェクトは、最初にリリースされたときよりも10?100倍の速度で比較的簡単に作成できます。市場投入までの時間を迫られる中で、単純かつ迅速に作業を行うソリューションを選択することは、賢明で効果的ですが、他のソリューションより効率的ではありません。しかし、パフォーマンスはユーザビリティの一部であり、しばしば最終的にはより慎重に検討する必要があります。

非常に複雑なシステムのパフォーマンスを向上させるための鍵は、ボトルネック*やリソースの大部分が消費される場所を見つけるのに十分に分析することです。計算時間のわずか1％を占める関数の最適化にはあまり意味がありません。経験則として、システムやシステムの重要な部分を少なくとも2倍速くすると思わない限り、何かをする前に慎重に考える必要があります。通常これを行う方法があります。変更に必要なテストと品質保証の努力を検討してください。それぞれの変更によってテストの負担がかかりますので、いくつかの大きな変更を加える方がはるかに優れています。

何かを2倍に改善した後は、システムの中で次に高価なボトルネックを発見するために少なくとも再考し、再分析する必要があります。

多くの場合、パフォーマンスのボトルネックは、頭を数える代わりに、足を数え、4で割ることによって牛を数える例になります。たとえば、リレーショナルデータベースシステムに適切なインデックスを付けることができず、多くの検索を行うと、少なくとも20倍遅くなるなどのエラーが発生しました。他の例としては、内部ループで不必要なI / Oを実行し、不要なデバッグ文を残したり、不必要なメモリ割り当て、特にパフォーマンスに関して文書化されていないライブラリやその他のサブシステムを使用することが挙げられます。この種の改善は時々「低掛けの果実」と呼ばれ、いくつかの利点を提供するために簡単に選ぶことができます。

ぶら下がっている果物が足りなくなってから、あなたは何をしますか？さて、あなたはもっと上に行くことができる、または木をチョップする。小さな改善を続けることも、システムやサブシステムを真剣に再設計することもできます。 （これは、新しい設計だけでなく、上司にこれが良い考えであることを納得させる良いプログラマーとしてのあなたのスキルを使用する絶好の機会です。）しかし、サブシステムの再設計について論じる前に、あなたの提案がそれを5?10倍良くするかどうかにかかわらず、

Next [How to Optimize Loops](07-How to Optimize Loops.md)

[//]: # (Version:1.0.0)

時には、実行に時間がかかり、製品のボトルネックとなるループや再帰関数が発生することがあります。ループを少し早くする前に、完全に削除する方法があるかどうかを検討して、数分を費やしてください。別のアルゴリズムがやりますか？他に何かを計算しながらそれを計算できますか？回避策が見つからない場合は、ループを最適化することができます。これは簡単です。物を動かす。結局のところ、これには独創性だけでなく、各種類の陳述と表現の費用の理解も必要となります。ここにいくつかの提案があります：

- 浮動小数点演算を削除します。

- 新しいメモリブロックを不必要に割り当てないでください。

- 定数を一緒に折りたたみます。

- I / Oをバッファに移動する。

- 分裂しないでください。

- 高価な型キャストをしないでください。

- インデックスを再計算するのではなく、ポインタを移動する。

これらの各操作のコストは、特定のシステムによって異なります。いくつかのシステムでは、コンパイラとハードウェアがこれらのことを行います。明確で効率的なコードは、特定のプラットフォームの理解を必要とするコードよりも優れています。

Next [How to Deal with I/O Expense](08-How to Deal with IO Expense.md)

[//]: # (Version:1.0.0)

多くの問題に対して、プロセッサはハードウェアデバイスとの通信コストに比べて高速です。このコストは、通常はI / Oと省略され、ネットワークコスト、ディスクI / O、データベースクエリ、ファイルI / O、およびプロセッサにあまり近接しないハードウェアの使用などが含まれます。したがって、高速なシステムを構築することは、しばしばいくつかのきついループでコードを改善すること、またはアルゴリズムを改善することよりもI / Oを改善することの問題です。

I / Oを改善するには、キャッシングと表現の2つの非常に基本的なテクニックがあります。キャッシングは、その値のコピーをローカルに格納することでI / Oを回避して（一般的には何らかの抽象的な値の読み取りを避ける）、値を取得するためにI / Oは実行されません。キャッシングの第一の鍵は、どのデータがマスターであり、どのデータがコピーであるかを明確にすることです。マスター期間は1つだけです。キャッシングは、コピーが瞬時にマスターへの変更を反映できないことがあるという危険性をもたらします。

表現は、データをより効率的に表現することによってI / Oを安くするアプローチです。これは、人間の可読性や可搬性など、他の要求と緊張していることがよくあります。

表現は、最初の実装から2?3倍に改善されることがあります。これを行うための技術には、人間が読めるものの代わりにバイナリ表現を使用すること、長いシンボルをエンコードする必要がないようにシンボルの辞書を送信すること、そして極端にハフマン符号化のようなことが含まれます。

時には可能な第3の技法は、計算をデータに近づけることによって参照の局所性を改善することである。たとえば、データベースからいくつかのデータを読み込み、集計などの単純なものを計算する場合は、データベースサーバーで取得してください。これはあなたが作業しているシステムの種類に大きく依存しますが、それを調べる必要があります。

Next [How to Manage Memory](09-How to Manage Memory.md)