この間他の人が作ったコードを実行したのけれど、そこにバグがあってつらーってなりました。 でもそのコード自分もレビューしてたし、なんで見つけられなかったのかなーって考えたことをまとめます。
作成した実装が本番で動くまで
まず、実装したものが本番にデプロイされて動くまでにいくつかのチェックが通ります。それぞれのチェックについて紹介していきます。
1.テストコード&実装者チェック&コードレビュー
ここでは実装者がテストコードの作成と、実機を用いた動作確認をします。 大体のバグはここで見つかります。 またテストコードが作成された時点でプログラマ同士のコードレビューが入ります。 読みにくいコードはないか、実装が仕様とあっているか、負荷を考慮したコードになっているかetcをみていきます。
2.開発者チェック
次に担当開発者全員で集まってチェックします。ここではバグはもちらん、作ったモノのクオリティをチェックします。 この時に、複数人で動かした際に生じるバグなどが見つかることがあります。 ここではクオリティ:バグ = 6:4ぐらいの比率で、チェックしていきます。
3.チームチェック
ここでは最終チェックです。担当開発者以外の第三者の目線からみてどうなのか確認するためにチーム全員でチェックします。ここではバグはほぼなくなっていてクオリティチェック、バグチェックの視点で見た時に 9:1ぐらいで、ほぼクオリティのチェックです。
4.QAチェック
ここでは専門の人テスターさんに、成果物のチェックをしてもらいます。ここでは仕様にそった実装になっているかをテストケースを元にテストしていってもらいます。 ここでは、あまり気づかないようなバグが見つかることが有ります。むしろそのためのチェックでもあります。
5.リリース前チェック
この時点で追加実装は完璧に動くものとして、既存機能が正常に動くかチェックしています。今回のバグは新規実装箇所でみつかるものだったのでここで見つかることはないですね。
なんで見つからなかったのか
見つからなかった原因を考えてみると、幾つものチェックが有るにせよ、今回のバグはコードレビューがしっかりできていなかったのが問題だったと思います。 コードレビューの質が落ちた原因として、
- レビュー期間が短い
- レビューにちゃんとした時間が取れなかった
この二点が大きいです。どうしてもスケジュール的に余裕がない状態だと、コードレビューのに避ける時間は削られがち今回がまさにそのパターンだったかなと。 もちろんスケジュールによって、時間が避けないことはよくあることだとおもいます。テスターさんが稼働できる時間や、申請日など様々な要因で起こりえます。そのような場合全て実装し終わって、本番化するまでの間に時間などがあるなら、そこで追加の実装や、新しい施策に取り組み始める前に、たまっていた負債を返済するための時間を設けて、そこで本当に本番化していいコードなのか精査するすればいいのかなと思いました。※1 なんにせよ、急いでつくっても負債は返そうってことです。 次回から意識していきたいですねね。
※1: あくまでサーバーサイドのアプリの話で、申請が必要なクライント側のアプリだと同じようないかないですね...つらい。
