【第61回】「悪いプログラム」のデバッグ

引き続き下流工程の話を。

何度か書いていますが、私が最初にこの業界に入ったのは小さなソフトウェア開発会社でした。

そこで数年間過ごし、最後は開発部のマネージャーになりましたが、実務上はバリバリの「プログラマ」でもあり続けました。

社内でチーム編成してプログラム開発するスタイルの場合、納品後に発見されたバグを、私が客先に出向いて修正することが多かったのです。

なぜかって？

若手はすぐに別の現場に行ってしまうからです。

それに、デバッグには特有の「コツ」みたいなものがありまして、私はそれがわりと得意でした。

そんな時代を過ごしてきたからか、私は生涯で「書いたプログラム」よりもはるかに「読んだプログラム」の方が多いはずです。

それよりも少し昔の頃、ある先輩にこう言われたことがあります。

「良い文章を書けるようになりたかったら、良い文章をたくさん読まなければならない。プログラムも一緒だ。良いプログラマになりたかったら、他人が書いた良いプログラムをたくさん読むべきだ」

私の場合、たくさん読んだのはどちらかと言うと「良いプログラム」ではなく、「悪いプログラム」でしたけど（笑）。

さて、デバッグ、特に納品してしまった、あるいは稼働開始してしまった「悪いプログラム」をデバッグする際のコツです。

バグが発生するプログラムのルートを、最小限まで絞り込んで修正しましょう。

もはや内部設計としてのモジュール構造の美しさなど気にしてはいけません。

「プログラム修正による影響範囲」を最小限に抑えることの方が重要です。

また、プログラム内に即値を入れることをためらわない方が良いことがあります。

コーディング規約で「即値禁止」となっていたとしても、そうすることが「最も安全かつスピーディな修正」になる場合、しかるべき人に相談してみましょう。

特に運用開始後のプログラム修正は、なにしろ「安全な修正」「影響範囲が少ない修正」が最も重要です。

当初開発する際に留意すべき点と、最終工程以降のデバッグ時に留意する点は異なることも多いのです。