プログラミングに付き物の「バグ」を直せるようになるには？ を考える記事も今回でひと区切り。今回は、"怒れるプログラマー"が生まれる背景を逆手にとって、デバッグ力を身に着ける方法を考えます。

第1回～第3回までの記事でも触れたように、バグ報告をされると不快感を示す"怒れるプログラマー"が生まれる要因には、大きくわけて次の3つがあります。

①バグがないのが当たり前という意識
②誤ったバグ報告
③バグ回避できる自信がない

この3つの要因について、どのように克服していくかを考えてみましょう。

①「バグがないのが当たり前という意識」を克服する

バグがないのは当たり前という意識を克服するには、大きな心理的抵抗があります。だって「バグがないのは当たり前」であってほしいですからね。

プログラマーとはいえ、他人が作ったソフトウェアやサービスを使うときにはユーザーの立場になりますから、「バグがあってもいい」という考えにはなりたくないものです。

逆に言うと、ユーザーとして「うるさい」人は、いざ自分が開発する側になったときに「バグがないのは当たり前」という意識に染まりやすくなります。

さらに、ユーザーとして「こんなバグを出す開発者は無能」などと開発者を罵ったり馬鹿にしてきた人は、いざ自分がバグを出したときの報告によって「無能」「バカ」と言われている気がして、怒ったり、バグの存在を認められなくなります。

開発の現場を知らないユーザーは、バグを出す＝無能、バグを出さない＝有能と考えてしまいがちですが、現場を知る立場になれば「開発当初にバグは多く存在し、デバッグを経てなくしていける」ということがわかります。やってはいけないのは、「バグの存在は許されるか、否か」と二元論的に考えることであり、これは開発の現場を知らない"外野"の考えであると言えるでしょう。

たとえ初心者でもプログラミングを始めたら、完成形だけを見ていたユーザー時代の"外野"的な意識を捨てる必要があります。ただしこれは、あくまで最終的には「バグがない」を目指すためのものですから、完成時の理想としての「バグがないのは当たり前」という意識まで捨てる必要はありません。

「バグが出るのは当たり前」という意識と「バグがないのは当たり前」という意識は、プログラマーにとっては共存できるものなのです。違いは、スタート地点にあるか、ゴールにあるかの違いでしかないのですから。

②「誤ったバグ報告」を克服する

誤ったバグ報告については、「他人が寄越す報告なんだから、受け手が誤りを克服できるわけがない」と思うかもしれませんが、それは少し違います。誤ったバグ報告は、ユーザーに対する情報不足からも起きるからです。

単純に使い方がわからなければ、ユーザーは適当に誤った操作をしてしまうことがあります。また、どのような結果が表れるかを充分明らかにしていなければ、おかしなことが起きたと思って報告してくることもあるでしょう。

大切なのは、そのような報告はプログラミングそのものによるバグではなかったとしても、伝えるべきことを伝えていないという"問題点"だと認めることです。ソフトウェアやサービスは、プログラムだけでできているわけではないのですから。

③「バグ回避できる自信がない」を克服する

最後の「バグ回避できる自信がない」を克服するために必要なのは"経験"です。

ただし、歳月をかけて経験を積む機会を待とうというわけではありません。その間、「バグを回避できる自信がない」状態で過ごすのはつらいことですし、プログラミングが楽しくないものになってしまうでしょう。

ですから、必要なのは「早く経験を積む方法」ということになります。そして、その方法のひとつとして、ここでは「ライブラリー」を作ることでをオススメします。

ライブラリーとは、プログラミングでよく使う処理を関数やサブルーチンとして再利用しやすくしたもののことです。

例えばファイルの中身を読み込んで表示するためには、多くのプログラミング言語で「指定ファイルをアクセス可能にする」「指定ファイルの中身を読み込む」「指定ファイルにアクセスできなくする」といったいくつかの手順を踏む必要があります。しかし、ファイルの中身を読み込むたびに毎回この手順を踏むのは面倒なうえに、手順を間違えば正常に動作せずバグが出ます。

そこで、このような何度も使うことになる処理をひとつのサブルーチンや関数にまとめて、自分用のよく使うルーチン集＝マイライブラリーにしておくことで流用しやすくしておくことが望ましいというわけです。

ライブラリーはプログラミングを楽にするものであると同時に、ここでは1段階多く経験を積めることが利点であり、ライブラリーを作る目的になります。使いそうな処理をあらかじめ、あるいは一度でも使った処理を早いうちにライブラリーにしておくことで、その処理を扱う経験を"+1"できるからです。

しかも前回触れたように、APIや既製のライブラリーにはそれなりの頻度でうまく動作しないものが紛れていることがありますが、自分のライブラリーを作る時点でそのことに気付ければ「そのAPIは使わない」といった方法での問題回避にも役立つのです。

例えば、文字を扱う処理を実行しようとしたときに「英数字ではうまくいくのに、日本語ではうまくいかない」ということはよくあることです。実用するプログラムの開発中にこのことに気付くと「どこが悪いのかわからない」ため修正がタイヘンです。ところが、ライブラリーの準備段階で気付けば、原因を特定しやすいのでデバッグが比較的容易になります。

おわりに

以上の3点に共通するのは、「後手に回らないこと」と言えるのではないでしょうか。「バグはないもの」だと思っているせいで、いざバグが出たときに慌てて混乱してしまうのが"怒れるプログラマー"の正体です。「バグが出るかもしれない」と思ってあらかじめ備えておき、バグに対して「先手を取る」ことができれば、慌てたり、混乱してしまわずに「バグがないプログラム」という理想に一歩近づけることでしょう。