バグを見つけ出すのに効果的な「説明メソッド」について
元ネタはプログラミングに関するものだけど、 プログラミングに限らず広い範囲に使えるメソッド発見。 WEB+DB PRESS vol.38「プログラミングの光景」(高林 哲)の中で 「バグの原因を見つけ出すにはこんな方法があるよね」 というのがいくつか挙げられていた。 その中で「そうそう、そうなんですよね」と激しく思ったのがこれ。 身近な人に相談する（説明しているうちに自分で原因に気づく） ある。 言うことを聞かないプログラムについて人に状況を説明していて 「ここでね、ほらちゃんと中身を置換してるはずでしょ、 なのにね、なぜか表示してもね、置き換わってない・・・ のは、二次元配列になっちゃってるからですね。」 と一方的に解決してしまうことはよくある。 これは何もプログラミングに限ったことではないように思う。 パズルをやっているにせよ人生の方向性に悩んでいるにせよ 自分でいくら考えてもどうにも
JavaScript開発における多段式エラープルーフについて - 若くない何かの悩み
第14回HTML5ビギナーズで、JavaScript のデバッグ作業を短くする「多段式エラープルーフ」について発表してきました。 スライド speakerdeck.com コードのサンプル github.com まとめ JavaScript のデバッグ作業を素早くこなすなら、多段式エラープルーフが必要です。
TDDでデバッグする - やっとむでぽん
バグを見つけたとき、どうするか。プログラマなら3つの選択肢がある。 直す 原因を調べる 再現テストをする プログラマなら、直感的に脊髄反射的に1番を選ばないだろうか。 バグを見つけた！ このへんが怪しい！ よし直そう！ やった直った！ というのが典型的なプログラマの動物的本能である。いや、そうであるかどうかは知らないけど、わたしはそうでした。 わたしがどういうデバッグをしていたかというと、当たりをつけて直してみて、直らなくて、アテが外れたなあホントはこっちがおかしいのかなーと、別のところも直してみて、ついでにあっちも直してみて、いろいろ直してるうちになにがどう正しいのかわからなくなって、いや待て落ち着け原因をちゃんと把握するんだっと思ってソースを改めて見直したり、print文を埋め込んで流れを追ってみたり、予想と違う動きをするんだけどそれはそれで正しかったり、考えたり唸ったりまたソースを見
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
