キャリア20年超。ずっとプログラマで生き延びている女のコラム。

バグが出る

»

 プログラムを書いているとバグが出ます。

 ソフトウェア工学の基本は「バグのないソフトウェアはない」だそうなので、当たり前といえば当たり前です。

 人間は間違えるのです。勘違いするのです。失敗するのです。

 人間のやることに完璧を求めてはいけないのです。

 それが分かっているにもかかわらず、わたしはいちいち腹を立てます。

 以前、「なんとかしてバグのないプログラムを書けないもんかなあ」と言ったら、「なに、その危険思想」と横に座っていた同僚に言われました。

 「えっ? 危険思想とまでいう?」

 「バグのないソフトウェアはない、だよ」

 「それは分かってるんだけどさあ。ものすごくたくさんプログラムを書けば、いつかバグを出さないようにできたりしないかなあ」

 「君にできることなら、それをできる人がすでに現れてそうなものだけど」

 「それもそうだねえ」

 なんていう会話をした記憶があります。

 バグといってもいろいろあるので、とりあえず「プログラマの自爆」が原因のものに限定すると、その発生要因は3パターンに分類できるんじゃないかと、わたしは考えています。

 1.注意が足りない
 2.思考が足りない
 3.知識が足りない

 「注意が足りない」というのは、変数名を取り違えたとか、初期値を設定し忘れたとか、単なるタイプミスとかいうことなんですが、これはもう撲滅しようがないと思っています。

 それでも、コードの書き方を工夫すればある程度は減らせるもんだと信じて、自分なりにマイコーディング規約をいろいろと決めていたりしますが。

 後はまあ、コードチェックをさぼらない、ということくらいですかね。

 次の「思考が足りない」というのは、考えることを途中で放棄して適当に書いちゃったり、深く考えずに通常パターンを適用したら実はそれが通用しなかった、とかいうことです。

 「もう一歩、踏み込んで考えれば気がついたかもしれない」と思うと、そこで思考を止めてしまった自分が悔しくて悔しくてしかたありません。

 とはいっても、仕事でやっている限りは時間に制限があるので、どこまでも考え続けるわけにはいかないわけです。

 それに、ずっと考えてると疲れるし、飽きるし……(←身もふたもない)。

 最後の「知識が足りない」というのは、けっこう致命的です。

 「足りない」ことに気付けなくって、間違いを間違いと知ることができないまま突き進んで、失敗をやらかすのです。このパターンのバグが発生した場合、原因の特定はかなり困難です。

 しかし、プログラミングに関する情報は膨大で、すべての知識を網羅することは実質的に不可能でしょう。

 「過去にこれで大丈夫だったから、今度も大丈夫だろ」とか悠長に構えていたら、バージョンアップによって状況が変わっていたとか、自分の中で正しかったことが間違いにすりかわっているなんてこともあったりします。獲得した知識がいつのまにか陳腐化している、というのは地味~にダメージ受けますよ、実際。

 それでも「昔はこれでよかったのに」と嘆いていても、動かないものは動かないのです。技術や環境の変化に対応して、こちらが変わっていかなければなりません。

 なかなか厳しい話ですが、変わらない=停滞している、ということでもありますから、自分がいる世界がより良いものを目指して模索を続けている限りはできるだけついていきたい、という気持ちを支えによろよろとついていっている次第です(苦笑)。

 この「知識が足りなくて発生するバグ」の対処法は「勉強する」しかないと思います。

 あとは、「これはこれで本当にいいんだっけ?」「もしかしたら他にもっといい方法があるんじゃない?」と常に疑うことでしょうか。

 プログラムを書いているとバグが出ます。

 それはしかたのないことだと分かっています。

 それでも、バグをつくった自分自身に対して「しかたない」と思えたことは一度もなくて、いつも「あの時にここを調べなおしてたら」とか「もうちょっとだけ気をつけてたら」と、ぐるぐる考えてしまいます。

 バグを許せないことが、わたしがプログラマを続けるモチベーションの1つになっているのかもしれません。

 まあ、それをあまりにも溜め込みすぎると精神的に追い詰められちゃうので、どこかでそれをまるめこんで「次からはこんな失敗をしないようにするぞ!」とかいった目標にすりかえていたりしますが。

 同僚がいった「危険思想」というのも、「そんなものを目指していたら精神的にキツすぎるだろう」という、忠告だったんだろうと思います。

 多分、バグを出す自分を許さないことも大事だし、許すことも大事です。バグに慣れないことも大事だし、慣れることも大事だと思います。要はすべてバランスなんでしょう。

 そんなこんなで、「バグのないプログラムを書く」という危険思想を捨てられないまま、わたしはいまだにプログラマを続けています。我ながら疲れる人です(苦笑)。

Comment(20)

コメント

インドリ

こんばんは。ひでみさん。
今回もプログラミング好きが喜ぶ良い記事でした。
プログラミング好きはバグを語りだすと止まらないですよね。
私もバグは嫌いだけどもその手の話題は好きという相反する気持ちがあり、この手のネタは長々と語り合いたくなります。
私もバグのないプログラムを書きたい派です。
バグを防げるであろう方法は何でも試しますし、同じぐらい発見方法もよく考えます。

> 3.知識が足りない

これが一番厄介なバグですよね・・・
これを防ぐために、日々鍛練をしております。
このバグの対処法は、「自分が知らない事を把握する」が良いかと思います。
何が知らないのかを正確に把握しておけば、その部分を抽象化して取り扱えますし、知らない事を知っておくと色々対処できますので、この手のバグを極力防ぐ事が出来ます。
あとは、継続的インテグレーションを実現できればいいと思います。
ただ、これが結構難しいんですよね・・・
何はともあれ、あきらめたら人間はそこでお終いです。
常に理想を実現するべく努力を怠らないのが一番のバグ対処法かもしれませんね♪

Soda

バグを出さないってのは、周りやお客に迷惑をかけないってことですが・・・
こーステータスというか、バグを出さないことがプライドになることもあるかなーと。
どんなに注意していても、防ぐことはできないわけですがね(^^;

>最後の「知識が足りない」というのは、けっこう致命的です。

気がつかない場合ですよねぇ。
思い込み、勘違いが主な原因ですかね。
いくら勉強しても、間違って覚えていたら意味がないわけですし・・・

#最近見た中で酷かったのは、SleepでCPUに負荷をかけているなんて例も・・・

何が足りないのか把握することなんて、できませんしね。
いや、できていたら、ハマることがないわけですからw

いかに先入観を消して、バグの切り分けができるのかってのが重要ですね。
そこで、自分の間違いに気がつけるかどうか・・・それに尽きるような気がします。
第三者の声が聞ける環境なら、気がつきやすいんですがねぇ。
なかなかそんな恵まれた状況にはならないわけで(^^;

まぁ、中には、第三者の声を聞いても、自分が正しいと思い込んでいるために、バグに気がつかない場合もあるのですが(^^;
自分に自信があるのは、悪いことではないですが、ありすぎるのも問題ですね。
バグ発生時に自分を疑うことも大切だと思っています。

現実的な線でみると、バグを出さないことよりも、バグを出したあとのフォローがうまくできるかどうかのほうが重要かなと。
・・・頭ではわかっているですがねぇ、それでもバグは出したくないですねw

forseti

私もバグが少ないと顧客に喜ばれるのですが、
バグを出している以上素直に喜べない人です^^:

バグを無くすまで行かなくとも、減らす手段としては
・レビューしやすいプログラムの作りにする事
・「お前(自分)はどうせこんなバグを生む」と自分に多いバグパターンを洗っておく
良いのか悪いのか、テスト終わった後にプログラムを眺めていると1つか2つはバグが引っかかります。

> SleepでCPUに負荷をかけているなんて
つい最近似たような事をやらかしました…。

ヴァン

こんにちは。

>3.知識が足りない

これは言っていられるように、

>「足りない」ことに気付けなくって

気づいていないことが重大だと思います。
知識が無いことを自覚していれば、無茶な事はしないでしょうし。

自覚していないがために、生半可な知識を振り回して、重大な問題を引き起こすのではないのでしょうか?

ひでみ

こんばんわです。ひでみです。
ちょっとだけご忠告ですが、よその話題をここに持ち込むのはマナー違反かと思います。これから先は削除させていただく可能性もありますよ?


インドリさん。

> プログラミング好きはバグを語りだすと止まらないですよね。

確かにプログラマはバグの話が好きですね。
いつもバグに苦労してるのに、なんでみんな生き生きとバグ談義をするのか……考えてみると不思議です(苦笑)。


Sodaさん。

> バグを出さないってのは、周りやお客に迷惑をかけないってことですが・・・
> こーステータスというか、バグを出さないことがプライドになることもあるかなーと。

そうなんですね。バグを出したくないのは、まず周りに迷惑をかけたくない、ということなんですが、たとえ一人でつくっていたとしてもやっぱりバグは出したくないんだろうなあ、と思います。

> 何が足りないのか把握することなんて、できませんしね。
> いや、できていたら、ハマることがないわけですからw

あからさまに足りないものはわかりやすいんですけど、ほんのちょっとだけ足りない、というのは特に把握がむずかしいです。
こういう場合にはこの値を設定しても無効、とか知らなくて「設定してるのに~」とジタバタしたり。
「こうなってるはず」という思い込みを捨てて、1行ずつ疑って調べなおすしかないですね。


forsetiさん。

> 良いのか悪いのか、テスト終わった後にプログラムを眺めていると1つか2つはバグが引っかかります。

私もよくやって、みなきゃよかったと思います(苦笑)。
テストが終わっちゃってるんでうかつに修正できないから、ものすごくストレスです。


ヴァンさん。

>>> 「足りない」ことに気付けなくって
> 気づいていないことが重大だと思います。
> 知識が無いことを自覚していれば、無茶な事はしないでしょうし。

足りないことで困っているのなら、調べればいいだけなので解決方法は単純なんですが、困る場面に遭遇してこなかったので足りないことに気づかなかった、というのは気づくのに時間がかかりがちなので、問題が発覚した時にはすでに致命傷、とかいうこともよくありますね。
発覚した段階でどれだけ的確に事態を収拾できるか、というのもエンジニアの技量のうちなんでしょうが。

επιστημη

ルール1: 優れた判断力は経験によって培われる。
ルール2: 経験は愚かな判断の積み重ねによって培われる。

ってのを思い出した(笑)

どんだけ長いことソフト屋やっててもバグは出しますねぇ。
しょもないバグはずいぶん減ったとは感じるけども。

現象から原因へのアタリをつけるのがうまくなるとか、
バグの匂いを感じることができるようになるとか、
次第に"神経すり減らして気をつける"ことをしなくて済むよになったように思います。

メソポタミア文明

バグださないか~
100%壊れませんと同じ感じですよねやっぱ、100には出来ないけど、99.999...と近づけていくしかないんでしょうね。

それとちょっと言葉汚いですけ、コメ欄関係ねえことよそでやれ。
問題出す側も返答する側もうざい。

Jitta

何をもって「バグ」と言いますか?あるいは、「仕様」と「バグ」の違いはなんですか?その前に、誰にとってのバグでしょう?

ユーザーが「バグだ!」と騒いでも、本当の所は仕様である事があります。提供者が「仕様だ!」と言っても、多くのユーザーがバグと認識する事があります。
この時、「バグ」か「仕様」かに振り分けるのは、誰でしょう?その振り分けは、どの様な視点で、どの様な基準のもとになされるのでしょう?


丁度、このやり取りが行われているんですねぇ。お目汚し申し訳ない。

インドリ

もっとバグのお話しがしたいので書きます。
バグを防ぐといえば、やはり攻撃的プログラミングですよね♪
あと、契約プログラミングかな。
それから、例外処理におけるポリシー設定などが重要ですよね。
他には自動テスト環境を整えて、テストが失敗したら直ぐに連絡が来るようにするとか・・・
ひでみさんは、攻撃的プログラミング、契約プログラミング、例外処理などといったバグ対策テクニックと、継続的インテグレーションの様な開発体制はどう思われますか?

ひでみ

こんばんわです。ひでみです。


επιστημηさん。

> 現象から原因へのアタリをつけるのがうまくなるとか、
> バグの匂いを感じることができるようになるとか、
> 次第に"神経すり減らして気をつける"ことをしなくて済むよになったように思います。

確かに昔に比べると神経すり減らしてる感じはしないですね。
年とって神経がず太くなっただけかもしれませんけど(笑)。
バグの原因探しもポイントがだいたいわかっているので、現象をみると原因ベスト10的なものが脳内に表示されて、それをトップからあたっていくとだいたいベスト3以内であたる、という感じです(←この表現で通じるのかなあ)。


メソポタミア文明さん。

> バグださないか~
> 100%壊れませんと同じ感じですよね

「100%壊れない」と言われて、本当に無謀なことめざしてるなあ、と実感できましたっ(苦笑)。
「100%壊れない」と言われたら詐欺を疑いますもんねえ、普通。


Jittaさん。

> 何をもって「バグ」と言いますか?
> あるいは、「仕様」と「バグ」の違いはなんですか?
> その前に、誰にとってのバグでしょう?

これはいろいろとむずかしい質問ですが、このコラムに限って言えばプログラマが心の底から「私が悪うございました」と言う部類のバグを指しています。「プログラマの自爆」というのはそういう意味です。
「プログラマの自爆」という枠をはずすと、バグの原因はそれこそ無限に広がっていくので、プログラマという視点しか持たない私にはとても分類整理することなんてできません。
「バグ」か「仕様」かについては私も日々、振り回されている問題なので関心はありますが、書き出すと単なるグチになってしまいそうで、コワくて書けないでいる次第です(苦笑)。


インドリさん。

不勉強で「攻撃的プログラミング」という言葉をインドリさんのコメントではじめて知りました。
なるほど~。最近ではそういう言い方をするんですねえ。
言葉を知らないで経験則でそんなことをしていました。
別に「攻撃的」とか「守備的」とかにこだわらないで、仕様によって、より適しているものをチョイスすればいいだけなんじゃないかなあ、と思うんですが。
でもまあ、そういった定義づけがなされることで、それを積極的に意識するようになるのはよいことだと思います。
私みたいに経験の中で会得すると時間がかかりますからね(苦笑)。

例外処理に関しては、はじめてその言語仕様をみた時は感動しました。
なんてすてきなアイディアなんだっ!
そんなすてきな例外処理によって解決される問題もあれば、例外処理ゆえに発生する問題もあります。
結局のところ、どんなすてきなアイディアもバグを生まないことは保証してくれない、ということです。

angel

素朴な疑問。
バグって適度に出ないと困りませんか? 品質管理の上で。
「バグ0件」なんて報告すると、疑いの眼差しが降り注ぎますよ。「本当に大丈夫か?」って。
大事なのはバグが無い事ではなく、収束していることだと思ってましたが。

>「知識が足りない」というのは、けっこう致命的です。

これは致命的ですね。これでバグが出ると、全体の品質を疑われますからね。
※挙句、その人の書いたコードが全面書き直しになったり…
なるべく早い段階で地雷になりそうな所を見つけて、重点的に勉強する/レクチャーを受けるなり、クロスチェックを徹底するなりして、後に引きずらないようにするしかないですね。

インドリ

そ記事の内容とずれていると思いますが・・・
バグはどうやっても0件にならないからその心配はありません。
疑われるのバグ検出能力だと思います。
そのプロジェクトに於いて、常に0件しか検出できないのであれば、先ずは検出能力を疑うべきです。
普通にテストしていると、0件なんて事ありえません。
バグは防ぐ能力と検出能力が大切なのです。
その為に、バグを埋め込んでみて、正常に検出できるのかを点検したりします。
バグ検出機能のバグをチェックするわけですね。

インドリ

失礼。消し残しがありました。
先頭文字の「そ」は無視して下さい。

岑(@IT自分戦略研究所)

編集部の岑です。
コメント欄で一部、コラムと無関係なやり取りがあると読者様からご指摘があり、
コラムと無関係な一部のコメントを削除いたしました。
無関係な内容はなるべく展開せず、ヒートアップしない程度にご投稿いただければ幸いです。
よろしくお願いいたします。

ところで、バグの話。
編集者からすると、文章の誤字脱字や校正ミス、語彙の誤りなどと
通じるところがあるなあ、と読みながら感じました。
「注意」「思考」「知識」……まさにその通り。
でも、ソフトウェアのバグと違って、誤字脱字や語彙の誤りは
努力すれば根絶できるのではないかな、と思いながら日々仕事をしています。

ひでみ

こんばんわです。ひでみです。


angelさん。

> バグって適度に出ないと困りませんか? 品質管理の上で。
> 「バグ0件」なんて報告すると、疑いの眼差しが降り注ぎますよ。「本当に大丈夫か?」って。
> 大事なのはバグが無い事ではなく、収束していることだと思ってましたが。

品質管理の観点でいくとおっしゃるとおりです。それが現実的な考え方です。
テストは「現実」にあわせて行わないと大変なことになります。
そういう現実はわきまえているつもりなんですが、理想をいえばやっぱり「バグ0件」をめざしたいんです。
「疑うんならとことん調べてみやがれっ!」って大見得を切りたいんです(そんなことこわくてとても言えないけどっ)。
現実は現実として、「完璧」を目指す気持ちは捨てたくない……というプログラマのあがきです。多分。


岑(@IT自分戦略研究所)さん。

いつもお世話になっております。お手数おかけして申し訳ありません。
個人的には、コメント欄てこういう現象も発生するよなあ、という感じでスルーできるレベルだったんですが……。
削除という手段は極力使いたくありませんし、岑さんもそういう想いでいらっしゃるんでしょうが、わざわざ指摘してくるほど不愉快な想いを読者様に抱かせたのなら、それもやむを得ません。
どうも私はそういった判断がゆるいようなので、ここのコメント欄に関しては厳しめに設定するくらいがちょうどよいのかもしれません。


私の判断があまくて、不愉快な想いをされた読者様には、本当に申し訳ありませんでした。管理人としてお侘び致します。
コメントをいただけるのは大変ありがたいことなので、できればずっとコメント欄は開いておきたいと思っています。
そのやりとりの中で多少の衝突が発生することもあるでしょうが、読者様の言葉を削除したり編集したりすることは本意ではありませんので、できればそのようなことにならないよう、ご協力いただければと思います。
よろしくお願いします。

ひろち

こんばんは。

「バグのないプログラムを書く」
私も目指しています。全然、危険思想だと思っていません。

趣旨とズレるのかもしれませんが、
手放したプログラムにバグが残っていても、
「バグのないソフトウェアはない」
と感じる方が、よっぽど危険思想だと思います。

ひでみ

こんばんわです。ひでみです。


ひろちさん。

> 手放したプログラムにバグが残っていても、「バグのないソフトウェアはない」
> と感じる方が、よっぽど危険思想だと思います。

言われてみれば確かにっ。
「バグのないソフトウェアはない」という言葉は、バグを出しちゃった時の言い訳のためにあるわけじゃないですもんね。
その事実を踏まえたうえで行動しろ、ということなんですよね、きっと。

Sero

テストして バグ来にけらし デスマーチ 始発来るまで 椅子の並べ寝
Seroぞう、心の一句…orz

ミントン

今日バグを出して、悔しくて「バグ 悔しい プラグラム」でググって、ひでみさんのコラムにたどり着いた、48才プログラマーのミントンです。危険思想上等。読みやすくてバグのないプログラムをかけるようになりたい。

かなめ

上流設計の段階で品質/仕様が十分に定義されていない事がバグを生む大きな原因の一つ
だとおもいます。品質=要求への適用度合い、なので。
どういう要求を満たさねばならないかが明確でないと
設計も実装もフワフワして思わぬミスにつながる、って感じでしょうか。
ミスはつきものですが、実装者が自身で行う単体テストの段階でキャッチアップして
自身でリカバリできてしまえばOKなわけですからね。

コメントを投稿する