良いプログラマを見分ける指標はいくつもあります。ひとつの指標で測れるほど単純なものではないからです。更にややこしいことに、作っているソフトウェアの分野や他のメンバーとの関係(スキルの得意不得意。文化的なこと)でも、プログラマの評価が変わります。

もし、ひとつしか指標を選べないとしたら、ぼくは「可読性の良いコードを書けるか」という指標を選びます。可読性が高くても、コードを書くのがとても遅いかもしれません。可読性が高くても、アルゴリズムやデータ構造の知識が無くて実行性能の低いコードしか書けないかもしれません。可読性が高くても、100行以下の短いコードしか書けないかもしれません、あるいは、入門書に載っている簡単な例題以上のことはできないかもしれません。まったく相関が無そうな指標もあります(＊1)。様々な可能性はありますが、可読性の高いコードを書ける人は、他の指標で良い基準に達している可能性が高い、という経験則です。作業速度や規模の大きな開発(設計)の力は、経験を積んで成長する可能性に賭けられますし、実行性能の低いコードの改善は、頭の中がマシン語でできているような人に任せることも可能です。

可読性の高いコードを書く動機づけとして、自分が以前書いたコードが読みづらくて困ったから、という理由を挙げれば、より高く評価します。

自分で書いたコードは、コンテキストを覚えている限り、自分で理解するのは簡単です。誰でもできます。しかし、他人が自分のコードを読んだ時、どう感じるかを想像することは容易ではありません。他人から、自分のコードを理解できないと言われた経験をしても、それを自分の問題として受け入れることはなかなかできません。自分が、他人の書いたコードを読んで理解できない経験をしても、自分の能力不足に帰着しがちです。

ある日、昔自分自身が書いたコードを読んで理解できない、という経験をすると、ショックを受けます。なんと言っても、かつては完璧に理解していた(＊2)コードが分からなくなっているのです。ここから、可読性の高いコードを書くための強い動機づけが生まれます。

コードを書いている最中は、そのことで頭が一杯なので、当たり前に思っていることがたくさんあります。これを(コードの外の)コンテキストと呼びたいと思います。コードを書いている人にとって、コンテキストは当たり前すぎて、それは誰でも知っているはずだ、と錯覚しがちです。コンテキストを理解できない他人が現れると、なんでそんなことも知らないのか、と憤ったりします。問題に集中している当人には重要でも、他の人から見れば、そんなこと知ったことか、ということも多々あります。そして、いつか未来の自分も、そんなこと知ったことか、という人のひとりになるかもしれません。

可読性の高いコードを書くということは、そこに想像が及ぶかです。

ぼくの理想のコードは、ソースコード＊だけ＊で完結しているコードです。余計なコンテキストに依存していなければ誰がいつ読んでも理解できるからです(＊3)。もちろん、これはありえません。なので、未来の自分が様々なことを忘れていても理解できる仕掛けをほどこします。それは名前のつけ方だったり、コメントでのメッセージだったりします。しかし、すべてをくどくどと説明はできません。時間もありませんし、そもそも情報量が増えると重要な情報が埋もれるという事実があります(＊4)。この辺の取捨選択のバランスは経験です。キーワードひとつでも未来の自分への気づきのメッセージとして充分な場合もあります。最も極端な例は、XXX コメントだけをつける場合です。「なにか思い出すべきコンテキストがあった」ことを、未来の自分に気づかせるサインだけで充分と判断した場合です。

さて、言うほど、これは簡単な話ではありません。例えば、HTTPを知らない人がコードを読むことまで想定してWebアプリを書くことに意味はあるでしょうか。意味があるとは思えません。プログラマなら当然知っているべき標準技術やアルゴリズムを知らない人まで想定する気はありません。これらの当然知っておくべき(と自分が思う)コンテキストと、上で挙げたコンテキストの区分は、非常に難しい話です。このバランスも、経験からとしか言いようが無いのかもしれません。

後者のコンテキストをドメインコンテキストと呼ぶとして、ドメインコンテキストをまったく知らない人を想定して、それぞれのコードを書くのはやりすぎです。コードのいたるところで、ドメインコンテキストの説明が必要になってしまいます。ドメインコンテキストの説明は、そのソフトウェア全体に付属した文書が負うべき責務です。コードを読む前に、これだけは背景知識として当然知っておくべき、という文書です。未来の自分がその文書の存在すら忘れたら、と心配するのは、まあ杞憂でしょう。そこまで言ったら、未来の自分はプログラミングを忘れているかもしれません。記憶喪失になった未来の自分が、コードを読んだ瞬間、色々なことを思い出したら素敵な話かもしれませんが、そんなことを想定してコードを書くのは病んでいます。

(＊1)「伽藍とバザール」(http://cruel.org/freeware/cathedral.html)に「何を書けばいいかわかってるのがよいプログラマ」というくだりがあります。可読性の良いコードを書く指標ではひっかけられない「良いプログラマ」のひとつのタイプです。

(＊2)今、自分の目の前のコードを、よく理解しないまま書いているプログラマは論外です。忘れて理解できないことと、そもそも理解せずに目の前のコードを書いていることは全然違う話です。

(＊3)結果論として、凝集度の高いコード、結合度の低いコードを目指すことになります(暗黙の依存関係なんて絶対忘れます)。これらは、本に書いてあるからそうするのではなく、自然とそうなるものなのです。

(＊4)今回のような話をすると、この「なんでも説明すべき症候群」に陥る人がいます。膨大な情報の中から、何が重要で、何が重要でないかを未来の自分が識別できると考えるのは、やはりこれもコンテキストに浸かっているからこそだと思います。じゃあ、どうすれば良いのか、と言われそうですが、経験から得たテクニックめいたものはありますが、披露できるほどの自信はありません。