こんにちは。鳥井雪です。
ヒューマンアカデミー こどもプログラミング教室の教材監修をしています。
ようやく緊急事態宣言も終了しましたね。少しずつでも、新しい日常をつくっていけるといいのですが。わたしも伸びに伸びた育休に終わりが見え、復職準備を進めています。さて、このコラムもいつもの内容に戻して、プログラマーが日常で考えていることをご紹介しますね。
バグ、という言葉は最近よく知られるようになってきた気がしますが、馴染みのない方もいらっしゃるかもしれません。プログラムを動かした時に、意図したとおりに動かないことです。“バグ”は「虫」の意味ですね。回路に虫が入り込んで、思わぬ動作をしてしまう...そんなイメージです。もちろん最近のコンピューターで、実際に虫が入り込むことは滅多にありません。ほとんどの場合、書いたプログラムに間違いがあります。その間違いを修正するのが、「バグ取り」です。
プログラマーの仕事時間は、多分みなさんが想像されるよりずっと、このバグとの戦いに費やされています。どんな熟練プログラマーでも、少し規模の大きなプログラムを書くと、一発で思い通りに動くことは（だいたいは）ありません。一度動かして、思うように動かず、原因を調べて、修正してまた動かして…と、完成に近づけていきます。書いたプログラムが一度で完璧に動くと、かえって「そんなはずない」と疑ってコードを見直してしまうくらいです。
バグの出方は色々あります。そもそも書き方が間違っていて動きもしない場合から、ある条件、たとえば1月1日の1時に実行した時だけ結果がおかしくなる、なんて気づきにくいものまで。なので、一旦これで大丈夫だと思って完成させたものが、ユーザーに使われるうちに「なんだかおかしいんですが」と報告がきて、バグとの戦いが始まるとこもあります…。
そんな時、プログラマが一番にやることはなんでしょう？おかしな動作をしたプログラムのコードを徹底的に見直す？ただちに修正を始める？いいえその前に、必ずやることがあります。それは、“もう一度そのバグを起こしてみる”こと。
Webアプリの場合、実際にお客さんが使っているサイトで起こすと色々不都合ですし、調査もしにくいので、本番のアプリとそっくりに動く、開発用のシステムでバグを再現します。どんなに単純そうなバグで、バグ報告だけ聞いて一瞬で直し方が分かった（気がした）としても、この「バグの再現」の手順を抜かすことはありません。なぜでしょう？
まず第一にはバグを起こしてから直さないと、本当に直ったのか分からないからです。
「トップページに、表示されるはずのない“aaa”という文字が出るという報告がお客さんからきているぞ。コードをみると、なんだか必要なさそうな変数の表示があるな。きっとこれだ、ここを消して、トップページを表示させて…よし何にもでない！直りましたよー！」ところが、その後再びお客さんから「やっぱり“aaa”という文字が出る。それどころか、今まで表示されていたログイン名がでない」という報告が…。
実は、“aaa”は、ある特別なメールアドレスでログインしたときにだけ表示されてしまうというバグだったのです。修正したプログラマーは、確認した時は自分のメールアドレスでログインしていたため、「たまたま」表示がでなかったのですね。それどころか消してしまったコードは、その特別なメールアドレスでログインした時に名前を表示するために必要だったというオチです。
こんなしょんぼりな事態を避けるためにも、必ず「バグが起こる状況」を再現して、それから修正に取り掛かり、再び同じ状況になってもバグが起こらないことを確認するのです。
もう一つ、バグを再現する利点があります。それは、「こういうことが起こるらしい」と聞いてから、「こうすれば起こるかな？こうかな？」と試しているうちに、バグの起こる“条件”が絞り込めるとこです。ある画面だけで起こる、あるアカウントでだけ起こる、ある日付だけで起こる…その条件が絞り込めれば、その項目について扱ったコードを中心に読んで調べることかきます。バグの原因である、プログラムの間違いにたどりつきやすくなるのです。
さて、日々このようにバグと闘うプログラマーは、日常生活でもミスが少なく…というふうにはいきません。しょっちゅう忘れものをしたり、電気を消し忘れたり、書類を出し忘れたりします（わたしは）。けれど、「なるほど、子どもを連れて帰ってきて、しかも荷物が多い場合に玄関の電気を消し忘れやすいな…?」など、ミスを起こしやすい条件に気付くこともあります。その気づきが、ミス防止の第一歩であることも身に染みて知っています。なにより、ミスやバグは人生につきもの、全部うまくいくなんてありえない。ちょっとずつ直していこう、という態度が身につくのが、プログラムを書きつづけることのいいところなのです。
一覧ページへ戻る