先週は当サイトの記事投稿数が少なくなっていたかと思いますが、実はとある受託案件が炎上しまして、その対応に追われていました。私も急遽そのプロジェクトにアサインされ、いくつかの不具合を修正したのですが、私が担当した修正は、見積よりも少ない時間で修正することができ、久しぶりにいい仕事ができたなーという感じです。
こういった火消し作業に投入されることが多い私は、今の開発メンバーの中では比較的デバッグが得意な方かと思います。今回の作業ではいずれも調査開始から15分以内に原因を特定できました。これはあたりをつけて原因を調べていくと大抵的中するためです。この精度の高さは経験則からくる”勘”のようなものだと捉えていましたが、思考プロセスを分解してみたところ、普段私がどういった点に着目してデバッグしているか、なんとなく言語化できたので、まとめてみることにしました。
デバッグの手順
以下のプロセスでデバッグを行っています。
- 再現条件を正確に把握する (手順、データ、etc…)
- なぜその事象が発生するのかを”事実”から推定し、仮説を立てる
- 仮説を検証する
- 原因を特定出来たら修正する
4はただの修正作業なのでいいとして、1, 2, 3を順を追って説明していきます。
再現手順を正確に把握する
始めにして最も重要な作業であると考えています。どの機能で、どの順番で、どんな操作をしたらその事象が発生するのか、100%再現する手順を確認します。ここを疎かにすると、後の作業が非常に大変になります。。。
この作業の目的は、原因の切り分け・絞り込みです。発生している事象と関係ありそうな処理・データ、関係ない処理・データを見極めることで、調査する範囲が絞り込まれ、問題がシンプルになることが多いです。
逆に言えば、再現手順が分からない不具合は、調査範囲を絞り込めないので泥沼化しがちです。そのような事態を避けるためにも、再現手順の把握はきっちり行います。
なぜその事象が発生するのかを”事実”から推定し、仮説を立てる
今回の主題であるデバッグのコツとはこのことで、いわゆる「あたりをつける」と呼ばれる作業です。私自身はここを経験則から無意識に行っていると認識していましたが、実際は帰納的推論によって論理的に結論を出しています。
ここで想像するのは、「現在の実装で、現在発生している不具合をおこす条件として、どこの処理orデータに異常があるべきか」です。今回の炎上案件で実際に対応した内容を例に挙げて説明します。
例. 住所検索の絞り込みの不具合
当社のソフトウェア資産の1つに、”住所検索コンポーネント”があります。データベースから住所情報を読み込み、都道府県→市区町村→大字…といったように、上位の住所レベルから順に選択していき、最終的に一意な住所を確定し、その座標に地図を移動させるといった機能をもつUIコンポーネントです。以下の図のような見た目です。
このコンポーネントには、「あ」「か」「さ」「た」「な」…など、読み仮名で住所を絞り込む機能があるのですが、ここに不具合がありました。連続する2つの住所レベルで、読み仮名で絞り込みを行うと、画面下部に表示される住所の候補リストの内容が、別の住所のものに置き換わってしまうというものです。つまり、以下のような事象が起きます。
- 市区町村一覧でA市を選択
- 大字の選択に移動→A市の大字一覧が表示される
- 読み仮名で絞り込みを実行
- なぜかB市の大字が一覧に表示される？
この”事実”から読み取れるのは、「大字の絞り込みの有無によって、市区町村を決定するパラメータが異なる」→「そのパラメータの値は市区町村の決定時に確定する」→「市区町村を絞り込んでいる時の市区町村決定処理にバグがある」などでしょうか。ここまで推定できれば、あとは何が起きているか大体想像がつきます。住所のリストは配列で管理されているので、絞り込み後の配列のインデックスで、絞り込み前の配列からデータを引っ張ってきたのだろう…とあたりをつけて実装を確認したところ、ビンゴでした。
実装の中身を知らない場合は、どのような作りになっているか想像できないといけないので、そこは経験則が必要ですが、そうでない場合は、上記の考え方で推定すれば比較的早く結論にたどり着けると思います。
仮説を検証する
あたりをつけた場所に不具合が無いか、実装を確認します。それっぽい箇所を見つけたら、修正して動作の変化を確認し、仮説が正しかったかを確認します。時にはあてが外れることもありますので、その場合は外れた仮説を除外して、2→3のサイクルを再び回します。
最後に
私なりのデバッグのノウハウという事でまとめてみました。誰かの役に立てばいいかなと思います。
