質問するために説明したら自己解決しちゃった！という経験が誰しもあると思うけど、その質問相手をテディベアにするのがベアプログラミング。
こういうのを
クマのぬいぐるみでやるクールな方法。
追記（2020年7月5日）
「ディスプレイの脇に置いたアヒルちゃんに実装した処理を一行ずつ説明する中で実装者自らがバグに気づき、デバグして品質を高める」ラバーダックデバッグっていう手法があるんだけど、絵面だけでも草なのにどうやらマジで効果絶大らしく、もうこんなん大草原不可避だわ。アヒルちゃん買ってこよ。 pic.twitter.com/80zqajvdPV
— なかめのくまちゃん (@wgextra) 2020年7月5日
追記：「プログラミング作法」の該当部分
自分のコードを他人に説明してみよう。自分のコードを誰かほかの人に説明して聞かせるのも効果的なテクニックだ。こうすると自分自身インバグが見えてくることが多い。場合によっては説明し始めた途端に気がついて「あ、もういいや、変なところがわかったよ。ごめん、ごめん」などと言って照れくさい思いをすることもある。このテクニックは意外なほど有効だし、聞き手は別にプログラマでなくてもかまわない。ある大学の計算機センターのヘルプデスクのそばにはテディベアのぬいぐるみが常備されており、摩訶不思議なバグに悩む学生は、人間のスタッフに相談する前にぬいぐるみに向かって説明しなければならないことになっていた。
（プログラミング作法 第5章 p. 173より)
他にもデバッグの部分の方針は知的創造作業では役に立つ知見満載。抜粋するプログラミング作法 5.2 「有力なてがかりのある簡単なバグ」より
- おなじみのパターンを見つけよう。見慣れたパターンなのかどうかを自問しよう
- 最新の変更点は要チェック。最後に変更したものに間違いが含まれていることが多い。少なくともひとつ前のバージョンを残しておこう
- 同じ間違いを繰り返すな。ひとつ間違いをみつけたら同じ間違いが存在すると考えて、それを全部修正しないといけない。
- デバッグは今すぐに。後で修正しようとしてそのまま忘れてしまう時は多々ある。
有名なのは火星探査機 mars Pathfinder のミッションで発生した事例だろう。1997年7月に無事着陸を果たした後、1日に約1回の割合で宇宙船のコンピュータにリセットが発生するようになったのだ。エンジニアたちは頭を抱えた。問題をつきとめたところ、彼らはその問題に見覚えがあった。そのリセットは発射前のテスト中にも発生していたのに、エンジニアたちが別の問題に忙殺されていたために無視されていたのだ。その結果エンジニアたちは後回しににしてしまった問題に対処しなければならなくなったが、そのときマシンは数千万キロも遠くにあり、修正作業は困難をきわめた。
（プログラミング作法 p. 171より）
- スタックトレースを取得しよう。これは、プログラムのデバッグ特有の話。強いて言うなら、うまくいかなくなったときのログ（うまくいかなかった結果含む）をちゃんと残しておけという話。
- 打つ前に読め。ソースコードを修正する前にまずどこを変更するべきかを熟考しようということ。
- 自分のコードを他人に説明してみよう。上述のとおり。
5.2 「手がかりのない困難なバグ」より
- バグを再現できるようにしよう。超重要！
- 分割統治しよう。超重要！原因として考えられるものを列挙し、他の要因が干渉しないようにして一つずつ間違いの原因を消していく。
- 誤動作を「数字占い」で検証しよう。発生するエラーについてそのエラーになにかパターンがないかどうかを見るということ。エラーについて特定の数値パターンが見いだせるならばその数値が何の数値に関連するのかを考えてみる。エラーの発生が1023バイトごとならば、この1023という2の10乗−1の値が何に関係するのかを連想していく。
- 出力表示によってバグ探索範囲を狭めよう
- 自己検証コードを記述しよう。超重要。確実に成功する値。確実に失敗する値。境界値などをあらかじめ明らかにしておきそれでチェックする。TDD! TDD!
- ログファイルを出力しよう。
- 作図しよう。超重要。図にしたりグラフにしたりすると見えなかった事柄に気が付くことがある。
- 記録をとろう。超重要。「バグの探索をしばらく続けていると、それまでに自分がどんなことを試し、どんなことが判明したのかがだんだんわからなくなってくる。」
5.5 「再現不能のバグ」にかかれていることも深い。「しかし、挙動が非決定性だという事実自体がひとつの情報を示している。」
