プログラムは思った通りには動かない【名言に学ぶ開発の心構え】

プログラマ界隈で言われる格言として、「プログラムは思った通りには動かない。書いた通りに動くのだ」(詠み人知らず)というものがあります。

オンライントレーニングのサイトを作った時にPHPとjQueryあたりをいじっていたのですが、Unityでゲームを作っている時とは比にならないくらいバグに遭遇しています。

プログラミングをしていて陥りがちなのが、「これで正しく動くはずなのに……」と何度も実行ボタンを押してしまうこと。

思い描いていた動きとは違う動きを信じられずに、同じ行動を繰り返してしまうんですね。かの天才アインシュタインはこのように言いました。「異なる結果を期待しながら同じ行動を繰り返すこと、これを狂気という」と。プログラマはこのような狂気にかられた行動をしているのです。

そんなことをしても書いたコードは変わらないので同じ結果を生み出し続けるのですが、なかなか切り替えられないのも人間のサガです。

書かれたものが正しい

人間が「思ったこと」と、実際に表現された「書かれたもの」の間にはギャップがあります。

自分で書いた文章でおかしなところってなかなか気付かないですよね。ブログを書いていて、書き終わった後に一度校正作業を行うのですが、半年くらい経ってから読み返すと「何でこんな誤字を……」というような誤字に出会うことがよくあります。

それでいて、他の人のブログを読んでいると「あ、誤字みっけ」とすぐに気付いたりします。不思議ですね。

私たちが書いたコードでも同じことがよく起きるんです。

自然言語でも日常茶飯事なのに、機械に意図を伝えるプログラミング言語ではそれはそれはよく見られる現象なのです。

頭の中で思い浮かべていた処理の順番をそのまま書いたつもりでも、プログラムの中では違う順番で書かれているなんてことは良くあることです。単純な誤字であればコンパイルエラーとしてコンパイラが拾ってくれますが、文法として正しいけどやっている順番がおかしい場合はなかなか気づけません。

Unityの場合は、ゲームを実行していておかしな動きをしていても、「いやいや、たまたまでしょう」ともう一度ゲーム実行ボタンを押してしまいたくなります。そして同じ動きを見てしまい、2度見てしまったからには見なかったことにできず、デバッグ作業に入っていくことになります。

(細かい話をすると、タイミングバグである可能性もあるため何回も確認するのは理にかなっていたりします。何度か実行して、同じ箇所でエラーが発生するという再現性を確認するのも大切なんですよね)

「画面は嘘つかない」

昔友達と遊んでいる時に、格ゲーだったか、何かの対戦ゲームだったか忘れましたが、私が「今の当たってないよ！」と言ったことがありました。

その時に友達に言われたのが「画面は嘘つかない」という言葉でした。頭の中で認識していることと、実際に私が指を動かした結果が現れている画面で起こっていることの間はズレがあることを意識できるようになった私にとって目から鱗の出来事でした。

ゲームに限って言えば確かに当たり判定に文句を言っているだけなのですが、この「ズレ」はゲーム以外の面でも起こりうるんですよね。

もう少し話を広げるならば、楽器の練習でも似たようなことがあります。どんな初心者だって下手くそな演奏をしようと思って楽器を演奏している訳ではありません。頭の中では超一流の演奏家のように滑らかに指を動かしている姿を思い描いているはずです。

それでもなかなかうまく演奏できないのは、頭の中の認識と指の運動との間にズレがあるからです。なので、自分の演奏を録音しておいてあとで聞き返し、「うわぁぁぁ聞きたくないいぃぃ」とまるで厨二病のノートを朗読させられているかのような辱めを受けながらフィードバックを得て、それをもとに練習して修正しているんです。

アウトプットしている最中というのは、脳内の理想の姿が重なってしまっているので、演奏中は自分の出している音をちゃんと聞くことができないんですよね。

意図と表現をつなげる

頭の中にある意図と、実際に書かれたコードを一致させるための作業がテストです。

頭の中で考えたプログラムをアウトプットするためには、情報を整理してコードの形でプログラミングしていきます。アウトプットのための情報整理の過程で、ある処理が抜けてしまっていたり、順番が入れ替わっていたりなんてことが発生します。多くの場合は自分がそのような状態であることを認識できないので、表現されたコードを動かしてみてフィードバックを受け取りながら修正を重ねていきます。

上で紹介した楽器の練習の例で触れたように、アウトプットしている最中は脳内にある理想の姿も重なってしまっているので、自分がおかしなコードを書いていても気付けないんですよね。だからこそ冷静にテストする必要があるんです。

以前の記事で「体当たりデバッグ」というものを紹介しましたが、これもテストの方法のひとつですね。

エクスプラボ

【体当たり開発】5分悩んで手がかりが無いなら全行にデバッグ文を仕込む

https://ekulabo.com/all-line-debug

「全行」というとちょっと盛りすぎですが、エラー発生時にどうしても手掛かりが見つからない場合はスタイリッシュに解決することを諦めて、全ての変数の中身を表示することで解決していきましょう。解決方法がかっこ良くするのではなく、問題を解決することがかっこいいのですから。

スマートに解決することを諦めて、現在の状態をしっかり確認すると問題点が明らかになってすぐ直せるようになります。

プログラミングで最も早くバグを解決する方法は、今どうなっているのか正確に把握すること。なのでデバッグ文の仕込みでも、慣れているならステップ実行でもどんどん使って現在の状態を正しく認識するようにしましょう。

スマートに決めるという呪い

スマートさというのはプログラマを縛る呪いになっていて、カッコよく決めたい、カッコよくバグを解決したい！という気持ちが生まれてくるんですよね。

真にカッコいいプログラマというのは、バグが出ても淡々と状態を確認し、問題を解決して、確実にバグを潰して「動く」プログラムを書ける人です。

意図と表現物を一致させることで、自分の思った通りのプログラムになります。

これをユーザーに使ってもらうことで、ユーザーの反応も正しく受け止めることができるようになります。

まとめ

プログラムは思った通りに動くのではなく、書いた通りに動くのです。

アウトプットを行っているときは、脳内の理想の姿を思い描きながらコードを書いているため、表現されたコードに何か不備があっても気付けません。なので、しっかりとテストを行なって意図と表現物を一致させましょう。

これはどんな人でも起こりうることなので気に病む必要は無く、淡々とクールにテストを行なって意図した通りにすればOKです。