悪い抽象化にコードを手錠されないために――良いメタファーの見つけ方

この記事は、数ヶ月前にメーリングリストでお送りした内容をもとにしています。毎週このような記事をお読みになりたい方は、こちらからぜひご登録ください。

以前の記事「ちょっとした便利さでプログラミングの流れを守る」では、シンプルな抽象化こそがコードベースを扱いやすく、楽なものにしてくれるという話をしました。

しかし、もし手元にあるのが悪い抽象化だったらどうでしょうか？

明らかに leaderboard と名付けるべきメソッドの実際の名前を調べるために、毎回APIリファレンスを掘り返す羽目になる。リファクタリングを試みても、ある部分のコードは構造化されたデータを渡してくるのに、別の部分は生のテキスト行を返してくる。そしてコードに触れるたびに何かが壊れ、position を変更したのに score を同時に更新しなかったばかりに、その日の残り時間をすべてデバッグに費やしてしまう。

では、どうすれば悪い抽象化から距離を保ちながら、良い抽象化を作れるのでしょうか？

良いメタファーで、より明快なコードを書く

良い抽象化は、良いメタファー（比喩）から生まれます。

メタファーとは、システム内の何かを、すでに頭の中にある概念に関連付けることで説明するものです。たとえば、こんな例があります。

• 多くのコマンドラインツールは、パイプというメタファーを採用しています。

  パイプの一端にデータを流し込めば、もう一端からデータが出てくる。イメージしやすく、直感的に使えるのです。

• 並行プログラミングにおいては、ロックが優れたメタファーです。

  内部の仕組みを一切知らなくても、リソースがロックされていれば使用できず、解除されるまで待つ必要があることがわかります。

• オブジェクト指向プログラミング（OOP）では、メッセージパッシングが特定のメンタルイメージを呼び起こします。

  あるオブジェクトが別のオブジェクトにメッセージを渡す。受け取った側は、そのメッセージで何らかの処理を行うか、さらに別の相手へ渡します。実装の詳細を知らなくても概念はつかめるため、プロキシパターンのようなデザインパターンの理解も格段に容易になります。

良いメタファーは非常に重要です。良いメタファーに基づいた抽象化に出会えば、ドキュメントを読んだりソースコードを掘り下げたりしなくても、コードを理解できることがほとんどです。優れたメタファーを見つけられるほど、自分のシステムを他の人に説明するのが簡単になり、後からそのシステムに取り組むときの手間も減ります。

良いメタファーはどうやって見つけるのか？

良いメタファーとは、具体的で自己完結的であり、対象の鮮明なメンタルイメージを作り出せるものです。誤解の余地を残さず、コードの実際の振る舞いとできる限り一致していなければなりません。誰かがメタファーへの理解をもとにコードについて仮定を立てたとき、その仮定が正しく成り立つべきなのです。

もちろん、良いメタファーを思いつくのは簡単ではありません。ぴったりのものに行き着く前に、穴だらけのメタファーをいくつか経由することもあるでしょう。それで大丈夫。練習を重ねれば、必ず上手になります。ここで、私自身が役立ててきたプロセスを紹介します。

まず、コードが「どのように」動いているかではなく、「何を」しているのかに思いを馳せてください。どんなイメージが浮かびますか？ 他のコードはそれをどう利用していますか？ 一言か二言で表現するとしたら、どんな言葉を選びますか？ それを書き留めておきましょう。

次に、そのイメージをじっくり検討します。それはコードの実際の動きと一致していますか？ メタファーから漏れ落ちてしまうエッジケースはありませんか？ 新しいコントリビューターがコードを使えるようになるまでに、メタファー以外に理解すべき事柄が残っていませんか？ メタファーを思い浮かべたとき、頭の中に鮮明な絵が浮かびますか、それともぼんやりしていますか？

これらは、メタファーがコードとまだ十分に一致していないことを示すサインです。とはいえ、良いメタファーに近づくほど、そこへ到達するための飛躍は小さくなっていきます。

最後に、そのメタファーを文章の中で使ってみましょう。「このコードは◯◯である。なぜなら…」。技術的なバックグラウンドを持たない人に説明しても、その役割を理解してもらえるでしょうか？ 背景知識が少なくて済むメタファーほど、多くの人の助けになるものです。

惜しいけれど決定的に違う――そんな場合は、類語辞典を開いてみてください。似た言葉同士の微妙なニュアンスの違いこそが、「まあまあのメタファー」と「完璧なメタファー」を分かつ境界線になり得ます。

メタファーとオブジェクト指向プログラミング

オブジェクト指向プログラミングは、根本的にメタファーの上に成り立っています。そこにこそ、OOPの真の力があります。よく設計されたクラスは、自らの実装を他のクラスから隠すだけでなく、あなた自身からも隠してくれるのです。

優れたメタファーが備わっていれば、クラス名を見ただけでオブジェクトの使い方がわかるはずです。クラス名が適切につけられており、頭の中に正しいイメージを喚起できるなら、使い方を把握するためにわざわざ実装を掘り下げる必要はありません。

それでは、最近あなたが触れたコードに登場するクラスについて考えてみてください。とりわけ明快なメタファーを持つクラスはありましたか？ どのクラスは「協働している」と感じられ、どのクラスは「戦っている」と感じられましたか？ また、使い方を調べるためにどれくらいの頻度で内部を覗き込んでいますか？

気づいたことがあれば、ぜひコメント欄で教えてください。

優れたソフトウェア開発者に短期間で成長したいなら、書いているコードや踏んでいるプロセスを意識的に考察する習慣が必要です。私がそのお手伝いをします。

無料の『Practicing Rails』32ページサンプルをダウンロードして、こうしたアイデアを小さな規模で試し、圧倒されることなく学び続ける方法を身につけましょう。