NTTグループのソリューションガイド
月刊ビジネスコミュニケーションによるエキスパートブログ
HOME | ABOUT |
atom rss2.0

« previous next »

影響調査

2012.07.06|通信ソフトウェア開発 このエントリーをはてなブックマークに追加Yahoo!ブックマークに登録この記事をクリップ!BuzzurlにブックマークBuzzurlにブックマーク

ソフトウェアのバグが見つかり、切羽詰った緊急対応するような時、発生したバグ対処で別のバグを作りこんでしまうような場合がある。とにかく緊急で10分、20分おきに、まだ治らないのか?というお叱りをうけるような場合、通常の作業手順では業務が回らなくないので作業の省略/簡略化をしてしまうのだ。

こういう局面で、通常の開発作業と較べて省略/簡略化してしまいがちなのが、レビュー、単体試験、影響調査だろう。緊急時は一番機能を熟知しているメンバがバグの設計やコーディングを実施することが多いため、その能力を過信してしまうことが原因ではないかと思う。例えば、影響調査というと、ある関数内でバグが見つかって、その関数の処理を見直す場合、その関数を呼んでいるルートを一通り確認して、見直した処理により悪影響を与えないかを確認する作業なので、ソースファイルで関数名をGrepしてその処理を確認すればいい。しかし、こういった地道が作業も記憶だけの照合で済ませてしまう。少し時間をとって確認していれば、、と思っても後の祭りである。

緊急対処したところは品質が悪いというのは、この業界の中では定説だろう。これはバグ対処に限らず、緊急機能追加等も含まれる。こんなときでもレビュー、単体試験、影響調査を踏ん張ってやることが良い成果につながってくるように思う。

Latest