デバッグ
エラーの位置発見の原則
考えよ : デバッグは問題解決型の過程。 最も有効な方法は、エラーに関係ある情報を頭の中で分析すること
行き詰ったら明日まで延ばそう : 人間の潜在意識は強い問題解決の力。 小さなプログラムなら 30 分、大きなプログラムなら 2, 3 時間考えて行き詰ったら、思考の効率が弱まっているということなので他のことをやるべし
行き詰ったときは問題を他人に説明しよう : そうすることで新しい発見があるはず
デバッグ道具は 2 番目の手段として使おう : ダンプとか追跡といった手段は、あくまで思考の補助として使う
実験を避けよう (実験は最後の手段) : プログラムを実験的に変更して問題を解決する、というようなことはデバッグとは言えない (成功のチャンスを減らすだけでなく、新たなエラーを追加することに繋がりやすい)
エラー修正の原則
1 つのバグがあるところには別のエラーもある可能性が高い : エラーは固まって存在する。 修正の際には他にも怪しいところがないか調べよう
エラーの兆候ではなく、エラーそのものを直そう : エラーの表面的な現象だけを修正してしまうこともある。 それはエラーの一部を直しているにすぎないので、根本的なエラーを直す
修正が正しいという確率は 100 % ではない : 「この修正は小さい変更なので問題ない」 と考える人が多い。 修正はプログラムのもとのコードよりエラーを生みやすい
修正が正しい確率は、プログラムが大きいほど小さくなる
エラー修正は新しいエラーを生む可能性がある : バグ自体は修正されても、副作用で別の問題を引き起こす可能性もある
エラー修正時には設計段階に戻ってみよう : エラー修正はプログラム設計の形式をもつことを理解すべし
オブジェクトコードではなく、ソースコードを変更する : オブジェクトコードを変更して後からソースコードを変更しよう、というようなことが起きがち
現代ではもうなさそう nobuoka.icon