バグはいつ直すの？（ソフトウェア分析）
バグを見つけたら
ソフトウェア開発で一番楽しいことはデバッギングです。これを楽しめるかどうかで、エンジニアの資質が決まります。ええ、バグを見つけたときにあなたが喜ぶか悲しむか、これが問題です。でも残念ながら、多くの人は悲しむ悲観主義でしょう。
バグを見つけたらデバッグします。当然です。そのままバグを飼うという方法もありますが、バグはわがままです。バグはどんな行動をするかがわかりません。きっと、あなたを驚かすことでしょう。悪い意味で。
いざ鎌倉、いざデバッグとなったときにどう行動するかの話です。今、デバッグしてもいいのでしょうか。それとも後回し、それとも放置、それとも誰かに丸投げ、それとも条件降付き降伏でしょうか。この戦略は重要です。
デバッグをするときは
楽しいデバッグそのものについては後日公開する記事にご期待ください。ここでは「デバッグはいつ直すの？」について考えていきます。
普通は、バグを見つけたら、ただちにデバッグします。当然です。もしあなたがGを見つけたら、ただちに何らかの処置をするのと同じです。同じ虫なのでバグの対処も同じです。基本はただちにデバッグするのが正義です。
でもこれができないときがあります。テストの最中にデバッグするのは勇気がいります。仕事を放りだすような気がします。また効率が悪いかもしれません。このときは確かに、気にしたら負けです。
この判断はテストのコストに依存します。単体テストはコストが小さいので、デバッグもその場で直ぐにします。そうです、バグがいたという証拠そのものを抹殺します。
一方、誰かの立ち合いの下でのテストは大変です。コストがかかります。このときは、デバッグは後日という判断になります。プランBの「戦略的撤退」になります。気にしたら負けです。
後回しにする理由（言い訳）
デバッグを後回しにするときは上記のように、テストにコストが掛かるときです。そしてその理由は(1) テストを中断したくない、(2) まとめてデバッグをした方が効率がいい、(3) そもそもテストをしている人とバグを作った人が違う、(4) テストと同時にするとソース管理が複雑怪奇、魑魅魍魎になるなどがあります。
そしてもう一つの理由は(5)そのバグを直す必要がない、があります。そうです、これも理由としてあります。これは言い逃れで使われる危険性はありますが、正しい判断のときもあります。この理由の言い出しっぺの人を見て、その判断をしましょう。
バグとつきあう
バグと仲良く付き合うことが大切です。今まで書いてきたように、バグをすぐに直す、後で直す、直さず放置の戦略を選択します。
この戦略の中で、放置するのは勇気がいります。放置プレーは慣れないと駄目です。バグをよく知っていれば、バグがどのような行動を起こすか、どのようなわがままをするかはわかりますので、そのときは仲良く飼ってあげましょう。仲良くなれば、そのバグは成長して、仕様と呼ばれるようになります。バグは孵化して仕様になります。
バグは未知の生物の場合、これは恐怖です。でもこの恐怖に打ち勝ってこそ、エンジニアです。防御壁を何重にも作り、監視プログラムで監視し、健康診断システムで自分の健康状態をチェックしましょう。これができて、一人前のエンジニアです。
ということで今日の結論。「バグはときがくるまで放置」以上です。
引用：ソフトウェア開発分析データ集2022 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
よろしければサポートをお願いします！