バグを作りこまないことの価値

前回までで、チーム開発におけるバグ管理の在り方についてみてきた。決してなくならないバグと改めて向き合い、付き合っていくことで生まれる効果を解説した。

バグはやはり多いより少ない方がよい。なぜなら、開発者による実装作業中にバグを発見し、即刻、駆除できた場合のコストに対して、テスト工程やそれ以降の工程、リリース、本番稼動中にバグが発見された場合のコストは、10倍にも、100倍にもなってしまうからだ。

本連載で見てきたようにバグには、多くの関係者が関わってくる。いったんバグとして認知されるとそれはもう開発者だけの問題ではなくなる。すなわちたった1件のバグに対して、多くの関係者の作業が少なからず増加することを示している。開発者が実装作業中にバグの芽を摘むことで、これらの作業コストが削減できるならば、それは開発チーム全体にとって非常に価値のあることになり得る。

そこで最終回の今回は、バグが作り込まれる前に駆除することに焦点を当てていく。開発者の実装作業を振り返りながら、開発者が実践できる品質の作り込みを行うための方法をいくつか紹介していこう。もちろん、ここでもバグ管理とソースコード管理が深く関わってくることになる。

開発者がバグの芽を摘むために、まずは開発者の実装作業を振り返ってみよう。

開発者の実装作業を振り返る

開発者はソースコードの記述だけではなく、その最中や完了時にいくつかの検証や確認を行っている。例えば、ビルドを行ってコンパイルエラーを修正したり、ビルドの成功後にデバッグを実行し、実行時の振る舞いを想定した操作やデータの入力を行い、期待通りの振る舞いを行っているか確認する。大規模開発においては、このような作業を、Visual Studioのような統合開発環境を用いて行っているだろう。

一通りの確認を終えて機能としての実装が完了したら、作成や変更したソースコードを結合（共有）することになる。ここで、コンパイルや振る舞いの確認を行わずに、ソースコードを結合（共有）することはお勧めできない。なぜならば、より多くのバグを誘発する危険性が高いからだ。

一度結合（共有）したソースコードにおけるバグは、バグ管理の対象とすべきであるため、いたずらにバグを増加させるやり方をとるべきではないだろう。また、ソースコードの結合（共有）にはソースコード管理システムを活用することをお勧めする。

さて、話を本筋に戻そう。上述した実装時の検証や確認はバグの芽を摘むための作業として十分であろうか。

ビルド時のコンパイルエラーの検知は、いわば構文の確認でしかない。また、デバッグ実行などを用いた自己判断での振る舞いの確認では、実行した操作や入力したデータ、そして実行の結果を詳細に記録しておかなければ、客観的な証拠とすることはできない。繰り返して振る舞いを確認するのも大幅にコストがかかることにもなる。

そこで、改めてバグを作りこまないためには、何を考えなければならないかを整理してみよう。 次のページ