海外のプログラマの机には、ゴム製のアヒルのおもちゃが置いてあることがあります。ふざけているわけではありません。アヒルに向かってコードを説明するという、由緒正しいデバッグ手法のためです。
やり方
- 詰まっているコードを開く
- アヒル(ぬいぐるみでも観葉植物でも可)に向かって、声に出して説明する
- 「この行は〜をしています。なぜなら〜」と、1行ずつ、飛ばさずに
- 説明が詰まった場所で止まる。そこがバグか、理解していない場所
本当にこれだけです。そして、驚くほどよく効きます。
なぜ効くのか
理由は、頭の中で読むときと、声に出すときで使っている脳の働きが違うからです。
黙読では、人は無意識に飛ばし読みをします。「ここはこういう意図で書いたから、まあ大丈夫」と、自分の意図で埋めてしまうのです。ところが声に出して他人に説明しようとすると、その省略ができません。相手は何も知らない前提で話すことになるからです。
そして「この行は……えっと、なんでこう書いたんだっけ」と詰まる瞬間が来ます。そこが穴です。理解していない場所を、自分の口が教えてくれるわけです。
うまくやるコツ
- 必ず声に出す(頭の中でやると、結局飛ばし読みになります)
- 意図と実際を分けて言う — 「ここで合計を出したい。実際には
sumにiを足している」。この2つがずれていたら、そこがバグです - 変数の値も口に出す — 「今
iは3で、sumは6です」 - 省略しない — 「ここは普通のfor文なので飛ばします」の「普通」に、たいてい犯人がいます
説明できない=まだ書くべきではない
この手法には、もう一つの使い道があります。書く前に使うのです。
これから書こうとしている処理を、コードにする前に声で説明してみる。すらすら言えるなら書けます。詰まるなら、まだ手順が固まっていないということです。そのまま書き始めれば、確実に迷子になります。
書けない原因は、たいてい文法を知らないことではありません。何をすればいいかが決まっていないことです。そういうときは第2トラックに戻って、分解と擬似コードをやり直すのが最短の道になります。
AI時代のラバーダック
今なら、アヒルの代わりにAIに説明するという手があります。しかもこの方法には、おまけが2つ付きます。
- 説明を書いているうちに自分で気づく(従来のラバーダック効果)
- 気づかなかった場合、その説明文がそのまま良い質問になっている
「動きません、助けて」と聞くのと、「この関数は合計を出すつもりです。3行目で i を足していますが、結果が1つ多くなります」と聞くのとでは、返ってくる答えの質がまるで違います。説明を書く行為そのものがデバッグなのだと考えてください。
この「自分の理解を言葉にする」習慣は、第6部でAIと組んで開発するときの土台にもなります。