TRAFFICというデバッグ手順

※こちらの記事はhayu自身の勉強のために「デバッグの理論と実践」を読んで書いた自己満記事です。ちゃんとした知識を得るには本を読みましょう。
https://www.oreilly.co.jp/books/9784873115931/

デバッグにおける7つの手順「TRAFFIC」というものがあります。
手順の頭文字をとって「TRAFFIC」らしいですよ。

T：Track 問題をデータベースに記録する

R：Reproduce 障害を再現する

A：Automate テストケースの自動化と単純化を行う

F：Find 感染源の疑いのある箇所を見つける

F：Focus 感染源の疑いが最も高いところに注目する

I：Isolate 感染の連鎖を分離する

C：Correct 欠陥を修正する

これらについて１つずつ着目していきます。

T：Track 問題をデータベースに記録する

デバッグの基本は「問題を見落とさないようにすること」にあります。
ですので、問題の記録を行うことが大事です。デバッガーなどの人間であったり、SmartBeatのようなツールであれば、問題発生時の再現方法やログなどの記録が録られることでしょう。

R：Reproduce 障害を再現する

問題を再現するために考えうる入力を考えます。これは問題を観察するため、そして問題が修正できるかを確認するために行います。
問題が再現できた場合、何が起こっているのかを観察することができるためプログラムコートから問題を推測することができます。
再現しない場合、潜在的な問題を推測したり、それを解決できる設計を考えます。しかしながら、問題を再現することができない限り、問題を解決したとの証明にはつながらないことが事実です。

A：Automate テストケースの自動化と単純化を行う

問題を再現することができた場合、次に行うことは「何が関連し、何が関連しないか」を特定することです。これを行うにはそもそもプログラムの単純化が重要となってきます。これについては熱く語りたいところなので後日にでも。。。

F：Find 感染源の疑いのある箇所を見つける
F：Focus 感染源の疑いが最も高いところに注目する

単純化を行うと、ある程度プログラムのどの辺がおかしいか推測することができます。観察できる範囲が少なければ、あとは実行しているロジックを観察ツールなどを使って観察します（breakPointなど）。そうすることで、「どこから実行結果がおかしいのか」調査範囲を絞り込むことが可能です。
問題発生源から出力までの流れを追います。感染状態は異常な状態を引き起こします。その異常な状態が感染の原因となっています。

I：Isolate 感染の連鎖を分離する

感染源がおおよそ推測できたら、そこを分離して観察します。

C：Correct 欠陥を修正する

あくまで、今までの工程は「推測」の範囲です。
ここで欠陥を修正して、問題が発生しなくなってから初めて「問題が解決した」と言えるわけですね。