他の名前でバラを呼べば、キャベツにしかならない

以前聞いた話です。何人かの人たちが話をして、アーキテクチャーにレイヤーを追加することにしたそうです。彼らはたまたま正しかったのですが、話が逆方向を向いていました。彼らは、ビジネスロジックを含むフレームワークを作ろうとしていました。ところが彼らは、具体的な問題を解決しようとはせず、データベースをラップしてオブジェクトを作ってくれるフレームワークが必要だ、という考え方からスタートしたのです。ORマッピング、メッセージ処理、ウェブサービス、その他ありとあらゆるすばらしい処理をするフレームワークが必要だと考えたのです。

残念ながら、彼らは、フレームワークがしてくれるすばらしいことが何かがわからなかったので、何と呼んだらよいのかわかりませんでした。結局、彼らは名前を募集したのです。本当なら、この時点で問題があるということに気付かなければなりません。あるものを何と呼んだらよいのかがわからなければ、それが何になるのかはわかりません。それが何なのかがわからなければ、落ち着いてコードを書くことはできないのです。

この例では、ソースコードのヒストリ情報全体をさっと見たときに問題の深さがわかりました。もちろん、「実装せよ」と書かれた空っぽのインターフェイスがたくさんありました。しかし本当におかしなことは、実際にコードがないのに3度も名前が変わっていたことです。最初の名前は、ClientAPIでした。このClientは、「クライアントーサーバー」のクライアントではなく、ビジネスのお客さんのことです。そして最終バージョンの名前は、ClientBusinessObjectsでした。すばらしい名前です。曖昧で、意味が広くて、誤解を招きやすい。

もちろん、名前は単なるポインタにすぎません。全員が名前はただ名前にすぎず、設計のメタファーではないことがわかれば、先に進めます。しかし、名前は十分に具体的なもので、間違っていたら間違っていることがわかるはずのものです。そのようなものについて意見が一致しないようでは、スタートを切ることさえ難しいでしょう。設計とは、システムの目標(速さ、安さ、柔軟性など)を満たすための試みであり、名前はその目標を表しているのです。

名前を付けられないようなものを書くことはできません。名前を3回変えたところで立ち止まり、何を作ろうとしているのかをはっきりさせるべきです。