Line 1: Error: Invalid Blog('by Esehara' )

または私は如何にして心配するのを止めてバグを愛するようになったか

>> Zanmemo

あと何かあれは 「esehara あっと じーめーる」 か @esehara まで

ほげWebフレームワークのパラドックス

 自分はWeb系プログラマーとして飯を食っているんだけれども、実は、この世界に入る前に、フレームワークを使わない素のPHPを使ってWebサービスを実装するという苦行を行ったことがある。一応、クラスで切り分けて、ユニットテストもして……ということをやっていたんだけど、それでも余りにも乱雑になりすぎて、メンテナンスが大変になって、結局潰れてしまった。そのあと、僕はWebエンジニアの世界に入り、Pythonという言語の、djangoというフレームワークを使って仕事をしている。そういう経験をしたあとに、やはりフレームワークがあるのは本当に楽だなあ、と思う。

 しかし、djangoで仕事をしているうちに、段々と不安になってきたことが一つだけあった。もちろん、djangoだから、仕事道具に詳しくなるのは当たり前であるのだが、Pythonとdjangoが余りにも密接になりすぎたことだ。もちろん、そういう人もいる。例えば、「Ruby on Rails」ではなく、「Ruby is Rails」みたいな人がいるように、だ。一つのフレームワークが好きな人もいることは間違いない。それはそのフレームワークの持つ生産性に惚れるからだろう。それは理解できる。しかし、僕がdjangoだけの話をしていると、段々と不安になってきてしまった。djangoのことを知ればしるほど、それってdjangoの外には通じない袋小路のような気がしたからだ。

 で、最近感じているこの違和感について、高名なハッカーの言葉である「ほげ言語のパラドックス」をパク……インスパイアさせてもらって「ほげWebフレームワークのパラドックス」と呼ぶといいような気がした。

 パラドックスには二つある。まず一つに、「フレームワークは、何かしらの物事を考えなくて済むためのものであるが、それをよりよく使うためには、そのフレームワークについて良く知らなければならない」というパラドックスだ。

 自分なりに、いろいろなWebフレームワークを試した結果(例えば、PHPのlaravelであったり、Node.jsのexpressも、一応アプリを立ち上げてみたくらいには書いてみた)、Webフレームワークは、その生産性と引き換えに、そのフレームワークの設計思想なるものに対して合わせる必要がある。そして、ある程度の規模になると、この設計思想に合わせることが、一つのコーディング規則として成立する。確かに、これは重要な側面である一方で、その設計思想から外れたことをしようとすると、途端に難易度があがる。また、そのフレームワークが想定している以外の(そして、この想定しているというのも測るのが難しいのだけれども)技術が飛び込んでくると、それを組み込むために、ちょっとした無理をしなければならなくなる。つまり、フレームワークの生産性と引き換えに、その設計思想に縛られる必要がある。

 そして、djangoにしろ(そしてたぶん「Ruby on Rails」も)、例えばテストであったりコマンドを発行したりみたいな機能があったりするが、しかしそれにたどり着く前に、骨が折れてしまう。その全体を理解するために、ドキュメントという地図を持って見回す必要がある。確かに、それを見つけたときは嬉しいんだけど!でも、それって何だか変だ。

 もう一つのパラドックス。もしかしたら上のパラドックスよりも重要かもしれない。それは「フレームワークを使いこなせるのは、そもそも軽量フレームワークでちゃんとした実装の出来るところだ」ということ。この言葉も、元々は「アジャイルの開発を廻せるチームは、ウォータフォール開発も廻せる」という皮肉をちょっと変えたものなんだけど。

 これは「Ruby on Rails」であったり、あるいは「djnago」、もしかしたら「CakePHP」を採用するようなスタートアップに陥りがちかもしれないが、確かにこれらのフレームワークはピカピカに磨かれた弾丸であり、無いよりは使う方が威力を発揮する。しかし、これらを採用すればすぐに解決するような銀の弾丸でないのも確かだ。フレームワークは、フレームワークというものの、決してMVCの理解であったり、あるいはORMの理解、そういったエコシステム全てを無視するようには出来ていない。上のフレームワークは、どちらにしろコントローラに、フォアグラにするカモのように、口になんでも突っ込むことが出来る。そうした結果、みるも無惨なアプリが出来てしまう。

 結局のところ、Webサービスを開発するときに、どういう設計をするべきなのか、そしてどういう開発手法をとるべきなのか、という根本的な問いは避けられない気がしている。

 確かに、「Rails」が切り開いたWebフレームワークという世界は素晴らしいものだ。だって、Webフレームワークはそれこそ「Rails以前」と「Rails以降」になってしまったのだから。それはそれとして認めつつも、しかし、あまりにもフルスタックなのは厳しいし、僕も実際のところ、「理念的には」、モジュールをかけあわせるほうが好きだ(この問題に関しては、実務的には、フレームワークがメンテナンスしているライブラリのほうがいいという現実的な問題はある。原石のように尖ったライブラリがメンテナンスされずに放置されている姿はなんども見てきた)。

 Pythonの中でいうならば、フルスタックのdjangoよりも、ただルーティングとコントローラーがあるだけの軽量フレームワークのほうが扱いやすい、という声はなんども聞いている。例えば「APIを実装するときに、djangoだと荷が重すぎるから、flaskを使っている」という話であったり、あるいは「メンテナンスとチューニングの関係を考えたら、flaskのほうがいくらでもなんとかできる」という話であったり。そうそう。別にdjangoのようなフルスタックだけが正義ではないのだ。だから、誰かさんがTwitterでつぶやいていた「Node.jsは上手くやっている」というのも、そういう意味では納得出来るのだ。用は適所適材で、あるフレームワークだけに寄りかかるのは損である。ただそれだけのことだ。

 それは、実のところ「ほげ言語」と全く一緒なのかもしれない。