わたしがprintf()デバッグをしない理由 2009-03-22 - 未来のいつか/hyoshiokの日記
プログラマという職業について、もう25年くらいになるのであるが、その間にコンピュータのコストパフォーマンスは、それこそムーアの法則に従って、10万倍〜100万倍くらい向上した。にもかかわらづ、デバッグの方法というものの劇的な変化はほとんどみられない。 プログラミング入門書では、デバッグについて、ほとんど議論されていないし、仮にふれられていても、おざなりな方法というか、かなり邪険にあつかわれていたりする。プログラマの多くの時間がデバッグについやされていたとしてもだ。 たまたま手元にあった、C実践プログラミング(ISBN4-900900-64-8)という10年くらい前に買った参考書では、450ページのうちデバッガの利用については、4行ほど記述がある。たった4行である。診断用のprintf()を挿入するということは3ページにわたって記述されているのにだ。 流石に21世紀になってprintf()デ
デバッグ方法論 - 未来のいつか/hyoshiokの日記
「わたしがprintf()デバッグをしない理由」http://d.hatena.ne.jp/hyoshiok/20090322#p1 は思いのほか注目をあびた。せっかくなので、その続編とも言うべきことを書き記してみる。 ところで、皆さんは、誰にデバッグ方法を教えてもらったのだろうか？テストの方法を誰に教えてもらったのだろうか。あるいは、ソフトウェア開発方法論を誰に教えてもらったのだろうか。学校でならったのは、プログラミング言語の文法であり、アルゴリズムであり、コンピュータアーキテクチャであった。デバッグ方法は誰も教えてくれなかったので、見よう見まねで行っていたのが学生時代だったような気がする。 バイト先のちっちゃいソフトハウスでは、トラブルシューティングは二分検索でやるということを教えてもらったが、デバッグ方法についての、コーチはなかった。別のバイト先では、厳密なテスト方法について学んだが
デバッグに要する時間
おれプログラマなんだが、バグが発生したときにプロマネや客に 「どのくらいで直る？」 とか 「3時までに直してほしい」 とか言われる。 原因が特定できてれば「○○時間で直ります」とか言えるのだが、そうもいかない。 単純なスペルミスかもしれないしOSレベルのバグかもしれない。 たとえてみれば迷路の入り口で 「何時間でゴールに辿り着けますか？」と聞かれるようなもの。 迷路の大きさが10m×10mかもしれないし、1km×1kmかもしれないし、視界には入り口だけなのに 「何時間でゴール？」 って聞かれた気分だ。 「○○時間」なんてバカ正直な答えは無理なのだが、そこをうまく相手が納得するような答え方ができる人材は 「頭でっかち」とか「これだから技術系の人間は」なんて言われず「総合的な意味で仕事ができる」と重宝がられる。
Part5 エラーの原因を探れ！ - C/C は永久に不滅です！：ITpro
C/C++の実行プログラムはバイナリ・ファイルですから，テキスト・エディタで編集できるソースコードとの間には大きなギャップがあります。特に予期せぬエラーが発生するとそのギャップは問題解決の大きな障害になります。両者のギャップを埋めることで，C/C++のコンパイル～リンク～ロードの様子を探検してみましょう＊1。 プログラミングで誰もがお世話になるソフトウエアと言えば，コンパイラかインタプリタであろう。 正確な表現ではないが，コンパイラはソースコードから実行ファイルを生成し，インタプリタはソースコードをそのまま実行してくれる。その機能さえ知っていれば，両者をブラックボックスとして扱ってもプログラムは作成できる。実際，難しいことを知らなくてもプログラミングできるようにブラックボックス化が進んできたのが，現在の開発ツールであり開発環境だ。 20年前なら，ただコンパイルを実行するだけでも，複雑なコマ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
