【バグは０になるか】プログラマーとバグ(close connection about programmer and bug)

今回は、現場でミスしまくった自分への戒めとして、



また、バグについて再認識のために持論を書いてみる。
とても、現場では言えないが、、、（笑）
開き直ってると思われかねない。

　バグは完全には無くならない！？

バグを出してしまっていることは反省しなければいけないのだが（汗）
僕の持論としてバグは完全には無くなるものではないと思っている。


位置づけとしては数学の理論と同じである。
例えば、「両側に限りに無く伸びている線を」直線という理論は成立はするが、
完全な直線というのは現実には存在しない。
どれだけ長い線でも現実では途中で曲がってしまったり途切れてしまったりするもの だ。


同様にバグに関しても
限りなく０に近づけることは可能であるが、完全な０が成立する ことはないのではないだろうか。
（数学的な証明は全くしていないので悪しからず）

　そもそもバグってなに？

バグの語源は文字通り「虫」。歴史は結構古く1842年からそういった表現がされていた らしい。
エジソンなんかも使用していた表現だとか。
真空管に虫が入ることが原因の不具合が起こり（バグ）、虫の除去をしていた（デバッ グ）。
そこから派生し、プログラミングの改修を「デバッグ」と呼ぶようになり、問題箇所を 「バグ」と呼ぶようになったとのこと。
（間違っていたら、有識者、訂正をお願い致します。。。）

　プログラマとバグの関係

少し哲学的に考えてみよう。


・なければ不安になるものである
・発見してデバッグして初めて安心するものである
・気づけばすぐそばに在るものである
・前任者が残していった怠慢や低スキルである
・プロジェクトの燃えカスである
・いつでも自ら生み出せるものである
・バグのフィックスがコーディングの8割の時間である


簡単に言うと上記のようなものである。あって嬉しいものではないが、
無いと不安になってしまう。
他人が作ると腹が立つが、内心自分も生み出しているかと思うと
強く主張は出来ないものだ。


つまり、消えるものではないから、親しみをもって仲良くしていくしかない。
バグの個性を知って、それに合わせて潰していくのが良いと思う。

　プログラマが対峙するバグの分類

SI的な大規模開発では、大きく3種類のバグがあると思う。

１.OSS、アプリケーション、ミドルウェアなどのバグ


骨組みとなる部分にも頻度は少ないがバグが潜んでいるケースがある
例）
InternetExploerなどブラウザのバグ
Javaなど言語のバグ
Strutsなどフレームワークのバグ
APサーバーのバグ



2.プロジェクトで成果物として提供するプロダクトのバグ

今、まさに実装している中でバグが発生してしまうケース。
当事者は自分であったり、チーム内の別メンバーであったり。


例）こんなことがある

String str = "a"
if(str == a){
 //処理
 hoge();
}

例）こんなこともある

// TODO 自動生成されたメソッド・スタブ
public String getName(){
 return null
}

例）こんなこともある

 /**
  * 未実装
  */
public boolean createHoge(){
    String a = null;
    // a = hogehoge(); ここをコメントアウトするとうまくいく
     return a
}

3．その他既存システムのバグ


新規に実装している部分には何も問題がない場合。
また、大規模な統合システムなどになると、他システム連携や拡張などの際に発覚しやすい。
その時点でjarになっていたり、影響範囲が大きすぎるという理由で改修が困難だった りしてかなり厄介。

　バグにどう抗うか（プロジェクトとして）

・　確実な見積もりとリカバリ

プロジェクトとしてとても大事である。
そもそもSIerが正しい工数の見積もりをしていないと、作業時間が取れない。
つまり、テストやセルフチェック等がおろそかになってしまうわけで、
その分、品質は下がり、バグは増える。

・　テストファースト

テストコードを先に作成してから実装に入るという方式
メソッドや関数が無駄に膨らんだり、機能の混同などを防ぐとともに
確実にテストを実施することで品質を向上させる。

・　TDD

テスト駆動開発。前述のテストファーストでの開発を進める。
勉強していかないとなぁ。

・　古典的なウォータフォールをやめる

個人的には結構ウォータフォールの形式が嫌いである。
というのも、要件定義、設計のフェーズの段階で
検証が不十分であることがしばしばあるからだ。
プロトタイプ実装→テストを行った後、設計に入っても良いと思う。
検証に時間をかけることは結果的に全体の時間削減につながるのではないかと思う。


設計書がある種の「縛り」になってしまい、身動きが取れなくなってしまうからだ。

・　夜9時以降はコーディングをしない

別に9時じゃなくても良いし、夜中にハイになる人には当てはまらないかもしれない。

ただ、一般的には過度な残業をすれば個々人のパフォーマンスは下がる。
毎日定時退社でいいじゃないの。残業して行った作業は、午前中にする作業効率の何分の一なのか。

　バグにどう抗うか（コーディングの手法として）

・　リファクタリング

とても大事。なるべくソースは簡潔に。無駄な記述や処理はしない。
リファクタリングの上で意識を持ちたいのは以下の2つ
1．規約の徹底　設定より規約（Convention over Configuration）
2．繰り返しを避けよ（DRY : Don't repeat yourself）

・　可読性の重視

可読性が高ければ自ずとバグは発生しにくくなる。
変数名やメソッド名、クラス名が本当に大事である。それでプログラミングの5割ぐら いは終了している気さえする。
その他、ソース中のコメントも大事で、ラッピングしている外側ほど抽象的に、実際の アルゴリズムなどが関わる部分ほど具体的にすべきである。そうしないと各メソッドや 機能の重要度が分かりにくくなる。

・　手書きを避けてコピペをする

これは少し語弊があるかもしれない。ソースをまるまるコピペすることは良くないと僕 も思う。
しかし、パーツはコピペすべき。
全て手入力するとtypoが発生するし、不必要に時間がかかってしまうことがある。

　まとめ

バグは限りなく０に減らしていきましょう でも、バグがないものなんて作れないですよお客さん。
別に開き直っているわけじゃないけど。


だからこそ、きっちりと「ルール化」することで品質と信頼の担保を取りましょう。