はじめに
これは BeProud Advent Calendar 22日目の記事です。
https://adventar.org/calendars/3338
今まで業務でデバッグをやることが比較的多かったのかなと思うので、自分が日頃デバックで心掛けていることを簡単に書いてみます。
まずは落ち着く
焦ってもいいことないので、落ち着いて調査プランを練るのがいいです。
適切な情報をそろえる
バグの発生状況について、まずは確認が必要です。
どの操作でどういった手順で起きたのか？どの環境で起きたのか？別の環境でも起きるのか？発生頻度は？どのデータなのか？などなどです。
この手の情報はあって困ることはそうそうないので、取れるに越したことはないです。
また、調査進めながらでも、必要だとわかったものについてはつどお願いして情報を取るのは大事です。
裏取りをする
できることならバグの再現を行ったり、不具合が発生したデータを確認します。
ひょっとすると、報告者の勘違いがあったり不正確な情報であったりするためです。
確認を怠ることで、必要以上に調査に時間ががかかったり、不必要な対応が発生するかもしれません。
すぐにわかることから調査する
まずは簡単に試せるものや、すぐに結果がわかるものを優先します。
目安としては数分程度でわかる範囲です。
例えば、ログにエラー出力が出てるか、対象データはどうなってるのか、ソースコードで処理をざっと追ってみる、などです。
たとえ容易に結果が予想できることだとしても、調査コストがほぼかからないのなら、やるべきです。
やってみると意外と予想に反した結果がでることもあり、より無駄な労力を使わないためにも大事です。
また、二分探索を行う上でも、こういう確実な情報があると、調査がしやすくなります。
仮説を立てる
ある程度情報がそろうと、ここが怪しんじゃないかという予想が立てられるようになります。
仮説を立て、その仮説が正ならどうなるか、逆に誤ならどうなるかを考えましょう。
別データを書き換えたり、逆に書き換えなかったりしないか、ログに出力があるかないか、表示はどうなるか、などです。
そういったことを調査することで、仮説が正しいかどうかを検証していくことになります。
ここで大事なところは、別の仮説も立てられるかどうかです。
ここの考慮をしないと、間違った仮説の素に全く違った方向にいってしまい、遠回りをすることがあるためです。
いくつも仮説が立てられるなら、それを一つずつ潰していく調査をしていきます。
必要なら、これらを何回も繰り返すことで確度を上げていくことになります。
思い込みの排除
人間なので、何かしら先入観なり勘違いをしがちです。
バグ調査には邪魔で、大きく遠回りする要因になります。
自分は大丈夫と思うのではなく、自分は思い込みがどこかある、と常に思いましょう。
チームメイトに相談する
わからなくなったときは、チームメイトと雑談レベルでもいいので、相談するのがいいでしょう。
ラバーダック相手でも同様に、声に出して説明すると整理されてすぐにわかるようになることもあります。
また、岡目八目で、チームメイトが的確な助言をくれるかもしれません。
原因究明と対処
バグの原因がわかれば、あとはソースコードの修正や、データ修正などで対応することになります。
ここでバグの再現ができていると、確実な確認ができます。
ただし、タイミング問題などの再現が難しいものもについては、ステージング環境などに修正を適用して様子を見るのが無難でしょう。
おわりに
これ以外にもテクニック的な部分はありますが、簡単ではなくなるので、次以降の機会にしようと思います。
この記事の内容は当たり前だと思われるだと予想しますが、当たり前を当たり前として実践するのが大事だと思います。