デバッグ作業というのはプログラマにとって永遠になくならない作業ですよね。
そりゃ、もちろん最初からバグのないプログラムが書ければベストです。でも現実としてそれは無理です。必ずバグは混入します。
なのでデバッグ作業というのは絶対的になくならない作業です。
そして、このデバッグのやり方によってプログラマーとしての資質が問われるといっても過言ではなく、デバッグが苦手なプログラマは例外なくプログラマーの職業で活躍する事は難しいと言えます。
活躍しているプログラマーは全員デバッグも一流
私の経験上、素っ頓狂なデバッグしている人で「それでもプログラマーとしえては一流なんだよなぁ」と言う人を見た事がありません。
凄いなぁと一流だなぁと言う人は人の書いたプログラムのデバッグも早いです。
なぜデバッグの仕方が重要なのか？
なぜデバッグの仕方が重要なんでしょうか？
答えは明確にして単純。デバッグのセンスはプログラミングのセンスと直結するからです。
通常のプログラミングは細かく作って細かい単位で検証を繰り返して行くスタイルですよね。どんなに全体設計をしたとしても、コーディング作業が設計の検証になるので、ビッグバン的に大きなくくりで確認をするより、細かく検証を繰り返す方が誤りが怪我が少ない内に気が付けるので、修正が軽微になり、方向修正も少なくて済むので圧倒的に効率が良くなります。
つまりはプログラミング中も細かいデバッグを繰り返しているんですね。
なのでデバッグのセンスはそのままずばりプログラミングの作業にも出ちゃう訳です。
いきなり作り上げた所からテストを開始して、問題があっても上辺だけの原因を解決するだけ。数ある不具合をシラミ潰し的に修正してニッチもサッチもいかなくなる。そんな経験ありませんか？
プログラムセンスはデバッグの仕方を見ればわかってしまう訳です。
仕様バグとプログラムバグの対応の仕方を知っている
一流のプログラマーはバグの種別によって対応方法が異なる事を知っています。
まず、仕様バグとプログラムバグの違いを理解しましょう。
これ、意外と理解出来ていない人が多いんです。
仕様バグかプログラムのバグかを理解出来ていないと言うのではなく、対処の仕方を間違っている人が多いです。そして、自信のある人ほど対応を間違える傾向があるような気がします。
仕様バグとは
仕様バグとは言葉通り「仕様のバグ」です。
仕様書にはそう書かれているのに、実際に動かしてみたら矛盾が生じていたりとか、仕様書に記載がなく漏れている事で問題があったりと、仕様書が起因しているバグです。
要件定義や設計段階の上流工程で発生するバグの事です。
プログラムバグとは
対してプログラムバグは「プログラムのバグ」・・・そのまんまですね。
プログラムの記述ミスによってプログラムが仕様書通りに動いていない状態のバグです。
仕様バグとプログラムバグで対応が異なる
仕様バグの場合、プログラムバグとは対応の仕方が変わってくる事を知らずに、仕様バグなのにプログラムバグと同じ様に対応してしまう人がいます。
絶対的な決まりがあります。これはとても大切なことなので必ず覚えておいてください。
仕様バグは仕様書のバグです。プログラム側が対応してはダメなバグなんです。
仕様バグは仕様の検討を行い、仕様を修正してからプログラムを修正するのが鉄則です。この順序を取り違えている人がたくさんいます。
この対応をあやまると・・・こいつ本当に勝手なことをするなぁと思われたり、システムを理解出来ていないと思われます。
実際にプログラマが仕様バグなのに自分の判断で勝手に修正したがために、あちこちに全体仕様にそぐわない実装が埋め込まれ大変な目にあったプロジェクトを見たことがあります。
典型的なダメデバッグをする人の特徴
ここから先はプログラムバグに関しての記述です。
プログラムバグに対してデバッグの典型的なダメパターンです。
読む人が読んだら、こんなの常識でしょ？と思うことも出来ていない人が多いんです。
では、実際にどんなデバッグをしているんでしょうか？
再現方法が確定していない状態でデバッグをしている
デバッグで一番やってはいけないのが再現方法が確定していない状態で作業をやり続ける事ですよね。再現するかしないかわからないので調査に時間がかかります。
こういう人の特徴はいきなりブレークポイントをおいて変数の値を調べたり、最初から細かい作業をし始める傾向があります。
「あ、自分そうだ」と思ったあなた。注意が必要です。
根本原因を究明せずに修正をしている
目先の問題だけで直してしまう人。いるんです。
その変数の値がなぜそうなっているのか？を探さずに、ある変数の値がおかしいからそれに合わせて修正してしまう。
恐ろしい事に原因を究明せずに表面だけ取り繕って終わりにしてしまう人がいるんです。
影響範囲が見極められずに修正してしまう
いざ修正する時にその修正方法が他の仕様に影響があるのかどうかを修正前に確認しなくてはいけないのですが、それが出来ない人がいます。
観点が抜け落ちてしまっている人がいるんです。調査だけでなくテストでも抜け落ちいます。こういう人はその障害は修正出来るのですが、被害を拡大してしまいますので注意が必要です。
デバッグの基本
まずはデバッグの基本的な流れです。
- 確実に再現するオペレーションを見つける
- 再現条件を最小限のオペレーションまで絞り込む
- 仮設を立てて証明することを繰り返し、バグの根本原因を突き止める
- 修正範囲の影響箇所を割り出す
- 現在の工程で一番コストのかからない修正方法を実施する
大きなステップとしてはこんな感じなるかと思います。
確実に再現するオペレーションを見つける
これは必須です。100％再現する方法を見つけましょう。
メモリの状態などOSやミドルに依存してしまって100％再現がムズかしい事もありますが、原則は100％再現する方法を見つけないとダメです。
「OSやミドルにも依存する」根拠は見つけて置かなければダメでしょう。
あやふやな状態では絶対にバグは修正出来ません。
「○○をすると■■になる」
この状態に持っていくべきです。
たとえば、「△△をやった後に■■になる時がある」ではまだダメです。条件が揃っていないですし、もしかしたら△△側に■■になる原因は見つけられるかもしれませんが、根本にたどり着いていません。
確実に再現する方法を見つける様にしましょう。
再現条件のオペレーションを最小限の条件まで絞り込む
これも出来ていない人が多いです。
100％の再現のオペレーションや条件に不要なものが沢山入っているケースです。
これでは問題の特定に時間がかかりすぎてしまいます。
複数の条件や手順がある場合は、どこまで最小化出来るかしっかりと調査をすべきでしょう。
仮設を立てて証明をすることを繰り返し、バグの根本原因を突き止める
障害が発生する最小限の条件が見つかったら、なぜその様な事になるのか。プログラム的な仮設を立てます。
「このif文の条件に間違いがあって、意図しない処理が走っている」
「このfor文のループ回数が1回多い」
などと現象からプログラムの中で実際に発生していることの仮設を立てて証明をしていきます。
これを繰り返すことでバグの根本原因をしっかりと突き止めていきます。
修正範囲の影響箇所を割り出す
バグの根本を見つけたら、問題を発生させている箇所の影響箇所を調べる必要があります。これは絶対にやらなければならない事です。
他から沢山に使われているクラスやメソッドの場合は、おいそれと簡単に手を入れる訳にもいかないです。どれだけ他から利用されていて、その修正を行う事で他がどの様に影響をうけるのか？は調査必須です。
現在の工程で一番コストがかからない修正方法を実施する
影響範囲が見極められたら修正方法の検討に入ります。
工程がまだ浅い内なら思い切ってその箇所に手を入れる判断もありです。
しかし、開発工程も終盤にさしかかり、ましてやリリース間際な場合などは、その部分だけ切り出して修正なんて手も考えられます。
しっかりとその時の状況にあった修正をしていく必要があります。
プログラマーかコーダーか？の分岐点
ここまで書いてお気づきの方も多いと思いますが、デバッグ出来るか否かは「プログラマー」か「コーダー」かの分岐点でもあります。
デバッグ出来ない人には大きな単位では仕事を任せられませんし、プログラムの構造を理解して動けないので単純に与えられたものを組み上げて問題なく動作する所までの作業しか任せることが出来ません。要するにコーダーですよね。
デバッグが出来る人にはある程度の大きさの仕事を任せる事ができますし、プログラムの構造やシステム全体の構造を意識して設計も出来るので、仕事も必然的に高度になっていきます。
コメント