開発をする上で、どうしても発生するのがバグです。
バグのない開発ができれば言うことありませんが、実際はいろいろな原因で問題が発生するものです。
発生してしまったバグをどのようにデバッグすればいいのか、普段気をつけていることを整理してみたいと思います。

バグの再現

バグを発見すると、反射的に修正したくなるかもしれません。しかし、ここを我慢しましょう。
修正しようとする前に、まずそのバグが確実に発生するのかを確かめましょう。
バグが発生したりしなかったりする状況は、なにを修正するのかすらあいまいになってしまうため、無駄な時間を使うことになりかねないためです。
再現させるための前提として、サーバや開発言語を可能な限りバグが発生した環境と同じに揃えるなどして、１つ１つ不確定要素を潰すようにすると良いでしょう。

原因の特定

バグを再現できるようになったら、次は原因を特定しましょう。
原因を特定する方法はエンジニアの数だけやりかたがありますが、おおむねのところ共通する手法は以下になるのではないでしょうか。

01．仮説を立てる
02．ログなど事実（データなど）を収集する

実際のデバッグにおいては、２つのうちどちらか１つを使うというものではなく、両方の組み合わせになるかと思います。

注意すべきは、なにを調べたら良いのかわからず、闇雲に原因を調査することです。
とはいえ、実際に調査する方針がつかめないこともあるため、闇雲に調べる場合はせめてどのようなことを調査したのかを書きだしておくと、１つ１つ原因を追いこんでいくための助けになるかと思います。

用途に応じた修正

原因が特定できたら、いよいよ実際の修正を行いますが、ここでも考慮したいポイントがあります。

01．簡単で根本的な修正
02．難しくて根本的な修正
03．簡単で場当たり的な修正
04．難しくて場当たり的な修正

※根本的な修正とは、今後の変更や拡張性などを考慮した修正であり、場当たり的な修正とはとりあえず問題が解決していれば良いものとする修正を表します。

基本としては根本的な修正を行うべきですが、実際は１から４のうちどれを選ぶかは状況に左右されます。

場当たり的な修正が良くないとわかっていても、時間的な制約で選ばなければならないことがあります。
そのような場合はコメントを残したりチケットに登録したりと、後に対応することになったとき、少しでも楽になるようにすると良いかもしれません。
なにしろ自分で記述したコードであっても、１カ月後には忘れていることもあるためです。

修正の確認

問題が修正できたら、実際に修正できているのかを検証しましょう。
修正したての状態だと、特定の条件下のみでは意図通りの動きをするが、条件を変えたとたんに動かなくなる場合が多いためです。
特に、場当たり的な修正を実施した場合は、修正したことの副作用として別の場所でバグが発生するということすらありえます。
ここでハマると、場当たり的な修正→別の場所でバグが発生→場当たり的な修正……というループにハマってしまわないように気をつけたいところです。

まとめ

デバッグ方法を整理しましたが、書かれていることは当たり前のことかもしれません。
しかし、どのような状況でも上記ステップを着実に踏んで進められるかとなると、話が変わってきます。
ハマってしまうと、気がつくと闇雲に原因を探してしまっている……、ということは良くあります。

上記ステップを踏んでデバッグを行い、その上でどうしても解決できないバグがある場合はどうすれば良いものでしょうか？

答えの１つとはしては、その日は切り上げて帰って寝てしまうことです。

身も蓋もない答えかもしれません。しかし１日かかって解決しなかった問題が、次の日すっきりした頭で取り組むと１０分で解決するということが意外とあるためです。
だいたいの場合、解決方法は複数あるものだったりします。
頭がすっきりしているときに改めて取り組むことも、立派な解決策の１つであることを思い出せるようにしておきましょう！

日々多様化・複雑化していくあらゆるシーンに於いて、シームレスにアテンドするソリューション事業部はこちら

●Wantedly掲載情報(本当にやりたいことに辿り着きたい技術大好きエンジニア募集！)

●Wantedly掲載情報(エンジニア想いの環境でJavaやPHPにチャレンジしたいエンジニア募集！)

●Wantedly掲載情報(Angular/Reactを極めたいフロントエンジニア大募集！！)