MVCフレームワークのような、モノを作るにあたって煩雑になりがちな部分を吸収してくれるライブラリを嫌う人が時々いる。その嫌いな理由はいろいろあるのだけど、そういう人は「とにかく動くこと」を要求していて、細かいこと、例えばXSS脆弱性だとかの面倒さだとか、学習コストの高さだとかを嫌っているように思う。そういう自分も「フレームワークなんて馬鹿じゃない？」と思っていた時期があるし、今でさえふとそんな気分になることもあるので、どちらが駄目とかいう話ではない。ただ、フレームワークについてぼちぼち考えてみる。

　何しろ、フレームワークと言われるモノ全般が、とっつきにくいのは間違いない。最初のうちは、チュートリアルこそ作れるものの、そこから一歩でも外れようものならあっという間にバグの嵐、全く訳がわからなくなる。そこでヘルプを読んだり誰かのレポートを読んだりするのだが、結局駄目でソースコードまで読むことになる。まぁそのコストはフレームワークを一から作るコストよりは安いのだけど、少なくともちょっとしたアプリを１つ作るコストよりはよほど高い。この辺のコスト意識が好き嫌いを分けているのではないかなと思う。昔フレームワークが嫌いだったのはこの辺の感覚があった。

　じゃぁなんで今はsymfony使ったりして開発してるのか、というと、結局コストをかけて慣れてしまうことで、おおよそのものが作れるようになるし、何が出来て何が出来ない(出来無くないけどコストが高い)のか、がわかってきて、システムの提案時点でそこを外すように誘導できるから、ということがわかったからだ。外すように誘導する、という言い方は誤解を招きそうだが、要は「必須」ではないところに無駄にコストをかけると、プロジェクトの成功率も下がるしコストも高騰してお互い幸せじゃないんだから、「出来れば」のところは曲げてくれるといいなぁ、という話をするということ。これが出来るならばフレームワークを使うことに依る省コスト度合いはぐっと上がり、使うメリットも出てくるはず。

　もっとも、最近の悩みは海外の良くできたフレームワークは日本のウェブサイトの慣習をフォロー出来てない(確認画面とかさー)ので、そこの実装にむやみにコストがかかってしまうところか。良くできたプラグインを作ってしまえばいいのだけれど、なかなか難しいところなんだよなぁ。

　本当にぼちぼちな話すぎて、日常タグしか付けられない。