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

＞　3．知識が足りない

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

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

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

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

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

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

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

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

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

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

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

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

こんにちは。

>3．知識が足りない

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

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

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

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

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

インドリさん。

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

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

Ｓｏｄａさん。

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

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

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

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

forsetiさん。

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

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

ヴァンさん。

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

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

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

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

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

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

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

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

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

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

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

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

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

επιστημηさん。

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

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

メソポタミア文明さん。

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

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

Jittaさん。

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

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

インドリさん。

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

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

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

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

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

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

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

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

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

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

angelさん。

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

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

岑（＠IT自分戦略研究所）さん。

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

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

こんばんは。

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

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

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

ひろちさん。

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

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

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

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

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