最適なデバッグは可能性を潰していく事 - 神様なんて信じない僕らのために
minekoaさんのエントリを読んでいて、 「そうそう、コンパイラがこんなこと言うときは実際にはあんな事が起きてるんですよ」みたいな知識データベース。そしてコンパイラが検出出来ないタイプのバグについても、現象に「あれ？、どこかでみたぞ、これ」となる。そういう「良くあるパターン」の蓄積はデバッグのスピードアップに大きく貢献します。 正しい。けれど、それはそれとして。 根本的な問題として、「問題の切り分け」というのが出来ていないからデバッグ出来ないというのが、「デバッグができないこと」なのではないかと思います。 デバッグという基礎素養 - みねこあ 「最適なデバッグはまず適切で高い可能性から潰していく事、最後に残った事が真実」 だなあと思いました。 デバッグをするときに経験があると 「そうそう、こういうときはこれだよね」 というのが解ります。 ハングアップが一番簡単で、 スタックを見ても良いし
途中でreturn編 ちょっとりふぁくと - 神様なんて信じない僕らのために
とりあえず、関係のないところでつっこまれたのでちょっとりふぁくと。 あー、やっぱり。予想通り「ながら」処理の典型的なのが出てきました。「ながら」処理というのは複数の事を一度に実行しようとする実装です。 「ステータスを変更する必要があるかどうか？」を判断しながら「遷移先のステータスを決め」ながら「ステータスを変更する」という。わかりやすく言えば、一輪車に乗りながら頭にボールを乗せてバランスを取りながら焼きそばを食べるという必要性がほとんど説明できないコード。 困った事にC言語系だとこれが普通なんですが、こいつが多くのメンテナンス不能なコードとバグを生み出しているフリーザ級の悪の親玉。 http://d.hatena.ne.jp/y_nakanishi/20090123/1232728337 codepad それはそれでいいとして、 nextのStateの決定を処理するところは残る。 で、「途
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
