So-net無料ブログ作成
検索選択

重厚長大なフレームワークはあまり好きになれない


MVCフレームワークというのが昔からどうも好きになれません。

MVCパターンと言っても良いですが。




どうも好きになれない理由はなんだろうかと自分なりに考えると、僕があまり好きになれない環境は以下の要素が多く含まれていることに気づきました。



  • ファイルが不自然に分散する
  • ファイルの命名規則やファイルごとの規則が決まっている
  • 本筋のプログラム言語以外にフレームワーク固有の設定ファイルを書く必要がある
  • ディレクトリ構造が規定されている
  • デプロイしにくい
  • 独特のルールやしきたり(制約と呼ばれることもある)を覚える必要がある
  • ちょっと想定から外れることをしようとするとなんにもできない
  • 一部分をコピーしても動かない





ほとんどファイルに関する問題でした。

まあクラスごとにファイルを分けたい、という気持ちも解るのですが、分けたくないという気持ちもあるわけで、特にさほど大袈裟でもないプログラムを書くのにクラスごとに異なるファイルを作ることを要求されると弱ります。ぜんぜん楽しくないのです。




いわばこれって他人の敷いたレールの上を漠然と歩くような不思議なストレスがあって、そもそもそれができたらコンピュータ屋なんて因果な商売はやってないわけで。




それでさらに上記のなにが問題なのか、僕なりに共通項を見つけると、要するに、開発スピードを犠牲にするようなこと全般がイヤなのでした。






ハッカーと画家 コンピュータ時代の創造者たち




ポール・グラハムの「ハッカーと画家」によると、そもそもコンピュータ科学(計算機科学)とハックは違うものなのだと。優れたソフトウェア設計者はエンジニアではないのだと。




確かに、イメージでしかないけど、クラス階層ごとにディレクトリを整然と分け、命名規則に従ってコードを書くのは全くハッカーのように見えないような気がします。偏見ですけど。




グラハムによれば、ハッカーは設計図から書き始めたりせず、ハッカーにとってのプログラミング言語は清書用のペンではなくてラフスケッチを描く鉛筆なのだという。




こういう話にはもの凄く共感してしまうのです。




実際、プログラマと名乗る人には二種類の人種が居て、考えてからプログラムを書く人と、プログラムを書きながら考える人です。




前者は職業プログラマにとても向いていて、後者は趣味に留めるか、研究者になった方が良いと思います。考えながら書かれたプログラムは、それ自体がどれだけ画期的な代物であったとしても、実用には全く供さない、いわば良くできた模型だからです。




僕は残念ながら自分がとても後者のタイプであることを繰り返し思い知らされる出来事が成人する前にあり、それからはプログラムは研究と割り切ってプロトタイプだけを作るようにして、事業化できそうなネタがみつかったら、それをもとにアーキテクトが仕様書を書き、職業プログラマが完璧な製品に仕上げる、というプロセスを自然にとるようになっていました。




独立した直後は会社に僕一人しかいなかったので職業プログラマのまねごとをしてみたのですが、やっぱりテンで向いてませんでした。そういうわけで今は全くその手のものは書いていません。適材適所というやつです。




そういうやり方でプログラムを書くとき、重厚長大なフレームワークはもの凄い足枷になります。




でも不思議です。これはなぜなんでしょうか。




たとえば、Rubyそのもの、Pythonそのもの、HaskellやErlangでもいいですが、そうした言語そのものに触れるときは、とても楽しく快適に学べるのです。




しかしその上で動くフレームワークを勉強しようと思ったとたん、とてつもない拒絶反応が全身にジンマシンのように駆けめぐります。




フレームワークとそうでないものの違いのひとつは、部分と全体という話にも近いかもしれません。




フレームワークには大きな枠組みがあって、そのなかで変えるべきところを自分なりに変えれば、そのシステムを好きにすることができます。しかしあくまで「変えるべきところ」がどこなのか、「どのように変えるべき」なのかは他の数多くの制約に従わなければいけません。




たとえば、JavaのStrutsでごく普通のショッピングカートをプログラミングするのは簡単ですが、とあるリクエストが来たらサーバでサイトイメージのスナップショットをレンダリングして、そのレンダリングにはHotJavaなどの外部のクラスライブラリを使って・・・もしくは、その部分だけWindowsのIE7コンポーネントを使ってレンダリングするとか、リクエストを受け取って3Dのレンダリングを行ってその結果をJPEGエンコーディングして返すとか、とにかくそういうことをする、と考えると、もうStrutsでやるべきことではなくなります。




そんな処理をJavaでやるべきかどうか、という議論もありますが、Javaには一応、Java3Dなどのレンダリング機能やJNIがあるので、どちらかといえばできるはずですが、Strutsの設計時にはおよそ確実に想定されていないであろう処理をそういうフレームワークでやるのは不安です。というかたぶんそれは誰に聞いても正気ではないと言うでしょう。




しかしそれでもたとえば「サラ」のJavaで、つまりサーブレットやStrutsやその他プログラムの外的環境は言語処理系しかないという状況で、HTTPサーバの実装自体から始めれば、そんなややこしいプログラムも安心して書けます。




なにが怖いのかというと、なにかの環境やフレームワークに依存するプログラムを途中まで作ってしまってから、「この先にはどうも進めない」という事態が起きるのが怖いのです。




これは事前に緻密な設計をして、フレームワークの性能評価をしてから開発にかかるようなウォーターフォール式の開発スタイルではまず起きないことです。




しかしゲーム的なものの作り方というのは、ある意味でこうした行き当たりばったりなところというのがどうしてもあります。




 「ここをこうしてみたらどうだろう?こうしてみたら?」




そういう細かい試行錯誤を繰り返して、まるで一刀彫りの彫刻のように全体から細部へと削りだしていくのがゲーム的なプログラミングです。




たとえばゼビウスは、もともとベトナム戦争を題材にしたゲームとして作られていましたが、開発者がいなくなってしまったため、新入社員の遠藤雅伸さんがSFものに作り替えたという伝説があります。それくらいドラスティックに変わるのです。




Webサービスに強引にあてはめるとすれば、mixiを作ろうとしていたら途中で2ちゃんねるになってしまった、ようなものです。




ゲームのα版と普通のWebサービスのα版というのはその意味ではぜんぜん違って、ゲームのα版は最初から棄てるのが前提ですが、Webサービスのα版からβ版をゼロから作り直すことはほとんどありません。あるとしたらよほど設計がまずかった場合だけです。




そういうときにフレームワーク、特になにからなにまで揃った、All in Oneのフレームワークを見ると、いつも尻込みしてしまうのです。




お仕事で使うぶんには、こうした重厚長大なフレームワークというのは、実に様々なことに配慮されていて、様々なところで実績を積んでいて、様々に役立ちます。




なのですが、エンドユーザ向けコンテンツというのは、常にオンリーワンのシステムであることが要求される場合があるので、無茶苦茶特殊なクエリーが発行されるとか、普通なら有り得ないところに凄く負荷が掛かるとかということが実際に良く発生し、そうなるとやっぱり最初からフレームワークは怖くて使えない、ということになるのです。




実際、Strutsで作ってもらったシステムをしばらく運用していたのですが、どうしてもあることができなくて、PHPで作り直したりしました。




この手のフレームワークを使っていると、最後はフレームワークのソースコードまで修正する羽目になるので、結局は自分で作ってもそれほど劇的には変わらない、ということになることもしばしばです。




ソフトウェア工学の常識では、「メジャーなフレームワークを使え」が当然なのですし、それを否定する気は全くありませんが、フレームワークは巨大すぎると怖くて使えない、というフレームワークアレルギーみたいな可愛そうな人間がいることも事実なのです。僕のことですが。




それでもなんども似たようなコードを書いていたら、フレームワークとまではいかないまでも、自分なりに処理を綺麗にするものが欲しくて、PHP向けのフレームワークで軽いものはないのか調べてみたのですが、なんだかどれも重厚長大で、PHPを使うメリットがむしろ殆どなくなっているような気さえするものばかりでした。この場合のメリットってデプロイが簡単、くらいしかないかもしれません。




特にフレームワークというやつが、どれもこれもMVCパターンをベースに作っているというのが本当に怖い。そりゃ確かに分けた方が安全だと思いますが、僕はもう書き始めてから1分でなにか動くものが見たいのです。




ロクロを回すように、コードを書き始めたら少しずつでも実行結果が変化していって欲しい。




だから僕はいまでも echo "Hello"; から書き始めます。

とりあえずWebサーバが動作しているかとか、保存先のディレクトリはあってるのかとか、そっちのほうが気になる。




さすがに最近は自分のライブラリが揃ってきたので、require_once 'mylib.php"; echo "helo" みたいに書くことも多くなってきましたが、極論それだけです。




データ構造ですらも、特に分けたいとも思わないので、PHPでプログラムを書くときにクラスなんかまず作らないです。部下がクラス作らなかったら怒るけど、僕は作りません。製品じゃあるまいし。




そこから本当に面倒だと思っているロジックや機能だけとをとりあえず書いてみます。

「勝手にブログ評論」なら、まずストップワード認識。といっても数行。




それを書いたら、即実行。

実行結果を見て、考えて、なおして、また実行結果を見て考えてなおす、この繰り返し。

これがまさに彫刻を削る作業なワケです。




ものによっては、これで完成しちゃうこともあります。

実行結果を綺麗に見せたかったら、結果をRSSで吐き出してSafariにでもなんでも食わせればいい。

画像を出力するならJPEGでもPNGでも吐き出せばいい。




そしてそういう細かいプログラムを紡いで、なんとなくシステムっぽいものができる、と。




それでなんとなく一丁上がり。事業化できそうなら、開発部にまわして、設計からやり直して貰う。




こういうやり方で果たしてあっているのかわからないのですが、そういうものをポコポコつくるときに、重厚長大なフレームワークはむしろ邪魔です。




僕が肯定するのは、全体で500行くらいのフレームワーク。




たとえばprototype.jsはフレームワークと違うかもしれませんけど、あれはとても使いやすいし、いざというときにもソースが読みやすい。




使うのもソースをインクルードするだけで簡単だし、覚えることも少ない。それに、なにかprototype.jsの機能を使おうとするときにprototype.jsに精通していなければならないというわけでもないのです。




たとえばprototype.jsで最も便利な機能は $('hoge')でHTMLエレメントが拾えること。これだけで手放せなくなります。




こういう感じのフレームワークがもっと増えてくれて、用途にあわせて選べるといいと思うのです。




アンケートフォーム作成用とか、リッチテキストエディタ用とかゲーム開発用とかブログ用とかSNS用とか。

それぞれ500行程度だから、ドキュメントなんかなくてもソースを読めばだいたい動作が想像できるような。




まあこれくらい小規模だとフレームワークというよりもスケルトンコードに近いですが。

PHPみたいな言語もどきにはそのくらい気軽な方が合ってる気がするのですよ。




そういう、小粋なフレームワークってないのでしょうかねえ。


nice!(0)  コメント(0)  トラックバック(0) 

nice! 0

コメント 0

トラックバック 0

メッセージを送る

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。

×

この広告は1年以上新しい記事の更新がないブログに表示されております。