Fさんのプロジェクトはいまたいへん忙しい時期，いわゆる「火事場」となっています．結合テスト工程でバグが次々に発覚し，そのたびに修正に追われているからです．昨晩もあるやっかいなバグの修正にようやくけりを付け，新たにソース・コードをリリースしたばかりでした．
今日はもう一つ残った別のバグをやっつけるために，ほかのメンバとともに休日出勤したFさんでしたが，バグの切り分けに集中しようとしていたFさ んのところにリリース先に出張している部下のYさんから妙な連絡が入りました．昨日リリースしたソース・コードを組み込むと，修正されたはずのバグが消え ないばかりか，1週間前に修正したバグと似たような現象が再現したというのです．
「あっ，いかん．あまりテストせずにソース・コードを出したから，デグレったのか？注 でも，早く修正版を出してくれないと自分の立場がない，とかいっていたのはYじゃないか…」．
注：修正版で既存機能が損なわれる事象を「デグレード（degrade）」と呼ぶ．
早急につぶさなければならないバグが目の前にあって気が気ではないFさんは，念のため，修正前にはNGだったテスト項目を実行してみました．する と，何の問題もなくパスします．不審に思ったFさんは，とりあえず現状のエラーをメールにまとめて送ってくれないかとYさんに連絡しました．
30分後，Yさんから送られてきたエラーのリストを見ていたFさんの脳裏にあるでき事がよぎりました．「ちょっと待て．この間，新人のX君のソー ス・コード・レビューをやったばかりだな．X君のミスで何件かバグがカウントされてしまったから，注意しなかったっけ？ あの後もX君が原因を作ったバグが何件か修正されているはずだ．まさか…」．
いやな予感がしたFさんは，リリース先のYさんに頼んでソース・コードのタイム・スタンプをファイルに記録して送ってほしいと頼みました．すぐに 送られてきたリストのタイム・スタンプは，一部のファイルが明らかにFさんの事務所のタイム・スタンプと一致しません．その後，リリース先と事務所のソー ス・ファイルを差分比較ツールで比較して判明したことは，次のような事実でした．「X君が修正した7月5日，7月10日，7月15日の修正のうち，リリー ス先のソース・コードに反映されているのは7月15日分のみ．7月5日，7月10日の分は修正前の記述になっている」．
読者のみなさんの中に，連日の休日出勤で疲れたFさんの代わりにこのプロジェクトのソース管理を立て直してくれる人はいるでしょうか？
●●コメント●●
0 件のコメント:
コメントを投稿