bugfix 手順まとめ

bugfix手順なんて今更感がありますが、意外とこういうのって先輩エンジニアから教えてもらったりしないよなーと思ったので纏めてみました。

仕事のデキる先輩方は、この手順を並列且つ高速に回しているので、傍目からは何をしているのか正確に把握するのが難しかったりします。そして、若手エンジニアが見様見真似で同じことをやろうとして、大事なポイントが抜け落ちて大怪我をする。。なんて場面を結構見てきた、もとい自分も体験してきました。

これに限ったことじゃないけれど、エンジニアの世界ってプログラム言語レベルのことは結構教えてもらえるけど、こういう仕事の進め方を教える風土がないような。。僕が今までに見てきた現場だけでしょうか。(そういう意味では、僕自身は恵まれてたとは思いますが。。)

ここでbugfix手順をまとめることによって、後輩エンジニアの一助になれば。もちろん先輩エンジニアからの厳しい突っ込みも大歓迎です。

bugfix 手順

  1. 再現させる。
  2. 基本、再現確認をまず最初に行うべきである。顧客や他部署からどのような報告が入っていようと、再現させて自分の目で確認した方がいい。
  3. 仕様を確認する。
  4. ここで言う仕様の確認とは、該当のロジックを製作したときにどのような仕様だと約束していたのか、ではなく、現在時点で該当機能はどのような仕様であるべきか。を確認すること。製作時点では仕様であっても、現在その仕様がそぐわないのであれば、仕様バグとして対応する。
  5. バグかどうか判断する。
  6. 1. 2. を適切に行えれば、バグかどうかの判断は容易だと思う。バグでないのであれば、当然ながら以降の作業は行わない。また、バグであれば重要度についても確認すること。重要度によって次フェーズ以降のスピード感が変わってくる。重要じゃないバグを慌てて対応したり、重要なバグを放ったらかしにすることのないようにする。
  7. 障害箇所を特定する。
  8. 障害箇所が特定できれば、影響範囲も明らかになるはず。影響範囲の特定は次フェーズのテスト作成に関連するので、必ず事前に行うこと。
  9. テストを作成する。
  10. バグを修正しない限りパスできないテストを作成する。影響範囲についてもちゃんとフォローしておくこと。
  11. ロジックを修正する。
  12. テストを消化し、バグが再現しないことを確認する。
  13. 修正したロジックでテストがパスできることを確認。

*BTSに登録するとか報告書を書くとかそういう事務的なことは敢えて抜いてます。

もちろん、バグの内容によってはこの通りいかないこともあります。

一番ネックになってくるのが再現ですね。再現手順がわからないとか、本番環境じゃないと再現しないとか、宝くじレベルの確率でしか再現しないとか。クリティカルなバグで再現不能状態に陥ると、とりあえずアタリをつけて修正するなんてこともあります。

ただ、基本的には手順を守るのが最も早く、確実にバグを潰せる、ということは忘れてはいけないです。クリティカルなバグだから、時間に余裕がないから、再現させずに怪しいコードを修正する、っていうのはとっても危険です。