プログラミング地獄への道は“ベストプラクティス”で敷き詰められている

 Ruby on RailsのメジャーバージョンアップとなるRails4のリリースが近づいて来ました。先日、日本人(あるいはアジア人)として初めてRailsコアチームのコミッタとして迎え入れられた松田明氏によると、Railsの生みの親であるDavid Heinemeier Hansson氏(以下、通称のDHHを使います)は、プロジェクトをリードするという意味で活動が活発になっているそうです。

 そして最近のDHHは、ブログもよく書いています。彼は歯に衣着せぬ発言でも知られています。強い主張を持った(opinionated)なフレームワークの作者らしく、DHH自身もきわめてハッキリと物を言います。攻撃的とまでは言いませんが、IT業界や技術動向などでは割と何かをクソミソにけなしたりということをします。

 DHHが何かをけなすときは、だいたい何らかの鋭い洞察とパンチの効いた皮肉が含まれていて、Twitter上のつぶやきや、ブログは読んでいて非常に面白いです。たとえ話も上手で、印象に残ることが少なくありません。

 そんなDHHのブログを読んでいて最近なるほどなと思ったのが、

プログラミング地獄への道は、時期尚早に適用された“ベストプラクティス”で敷き詰められている――DHH

という言葉です(Winning is the worst thing that can happen in Vegasというブログエントリに出てきます)。

 これは「地獄への道は善意で敷き詰められている」という有名な言葉をもじったものです。この言葉、私はマルクスがオリジナルかと思っていましたが、どうも違うようですね。ともあれ、この言葉の意味するところは、善意から出てきた社会運動や政策提言でも、社会や人類に多大な害悪をもたらす結果になることがあるということです。社会主義は、人間が人間を搾取しない平等を目指すとした「善意」から起こった思想でしたが、結果として著しい停滞や貧困、独裁による地獄が現前したことは歴史に見るとおりです。しかし、それは元々は高邁な理想や人々の善意から起こった政治運動であり社会実験だったわけです。「地獄への道は善意で敷き詰められている」という言葉は、「善意ほど恐ろしいものはない、心せよ」という警句として読めます。

ラスベガスで起こり得る最悪のこと

 さて、DHHの言葉ですが、ブログエントリのタイトルは「Winning is the worst thing that can happen in Vegas」(ラスベガスで起こり得る最悪のこと)となっています。要点は以下の通りです。

 ラスベガスのカジノでは、割と早い段階で客に勝たせるようにできている。しかし、長い目で見れば、ちゃんとカジノ側がその分も含めて全てを取り戻すようになっている。

 ちょっとした勝利の高揚感がギャンブルに対して人を盲目にさせるのです。同様に、「すばらしいアーキテクチャで抽象化できた」という小さな勝利の高揚感によって、プログラマは「早すぎる抽象化」の罠に陥ることがあるというのがDHHの主張です。

 未来コーディングはカジノのルーレットで賭けをするのに非常に似ているとDHHは言います。未来コーディングというのはDHHの造語だと思いますが、将来に必要となることを考えながら設計やプログラミングをすることですね。将来こういう機能が必要だろうとか、こういう風に抽象化しておけば、プログラムの柔軟性が高くなって将来に変更が必要になっても対処できるというような「先を見越したプログラミング」です。これをやり過ぎるなというのがDHHの言っていることだと思います。YAGNI(You ain’t gonna need it. そんなもん必要にならねぇよ)という言葉もプログラマーの間では良く知られていると思いますが、「将来必要になりそうだから」と思って実装する機能は実際には不要なことが多いので実装のシンプルさを優先させるのが吉、ということですね。

柔軟性という名の技術的負債

 技術的負債というのは、整理がつかないまま汚いと知りつつしてしまったコミットや、クイックハックのことばかりではない。もっと潜在的に蓄積してくるのが「柔軟性」という名の負債だ、とDHHは喝破します。

 未来コーディングはルーレットで賭けるのに似て、当たるも八卦当たらぬも八卦。このため、「こういう感じのやつが、もっと増えたときのため」と思って行う、「早すぎる抽象化」「早すぎる抽出」(premature abstraction and extraction)というのは、全て少しずつ蓄積していって、技術的負債となるのだといいます。1970年台に「早すぎる最適化は諸悪の根源だ」と言ったドナルド・クヌース博士の警句に通じる話ですね。

 抽象化や抽出(メソッドやクラスを独立させるようなことでしょうか)、あるいはアーキテクチャー(デザインパターンのようなものでしょうか)といったもので、存在自体がイケてないものというのはほとんどない。「善意」と同じで、「ベストプラクティス」に、それそのものが悪いものというのはない。ただ、必要性がないのに適用されたベストプラクティスは、ほとんどすべて悪である――。これがDHHの指摘です。何の問題もないコードなのに、いきなり「ナントカファクトリー」という名前のクラスを足すとか、基底クラスを継承しているクラスが1個しかないという話でしょうか。DHHは、使わない引数を実装したメソッドや、どこからも呼ばれないパブリックメソッドに対しても「ノー」と言います。

 「設計の世界において最も難しく、そして最も重要なことは、“ノー”と言える信念だ」(DHH)

と、ブログを締めくくっています。

 先を見越した設計、行き当たりばったりでない設計の大切さは言うまでもないのでしょうけど、それがアダとなり得るというDHHの言葉は含蓄があるように思いました。

前の記事| 全コラム一覧へ |次の記事

投稿する

エンジニアライフ 最新の投稿コラム

@IT自分戦略研究所フォーラム 新着記事

コラムニスト プロフィール

西村賢
@IT編集部の西村賢がRuby/Rails関連を中心にブログしています。
Ruby on Rails情報の新コーナー「Rails Hub」をよろしく!

- PR -

イベントカレンダー

アクセスランキング

もっと見る