PHP初心者へのフレームワーク(たとえばSymfony 2とか)のススメ 〜 Symfony Advent Calendar JP 2011 15日目 このエントリーを含むはてなブックマーク Clip to Evernote

Symfony Advent Calendar JP 2011の15日目です。昨日は@ganchikuさんの「Symfony2 クックブックの主観的なおさらい Symfony Advent Calender 2011 JP -14日目」でした。いつもは、物欲ネタが多い本ブログですが、今日はプログラミングねた。PHPの代表的なフレームワークのひとつであるSynfonyのお話です。

で、本当はAsseticの話を書くなどとAdvent Calendarへの参加表明のときには書いていたのですが、ちょっと仕込みをしている時間がなくなってしまったこと、Asseticの概要はすでに軽く書かれちゃったので、あえて原点に立ち返ってフレームワークって何、おいしいの? というような話を皮切りに、Symfonyの話をしたいと思います。

というのも、ここ数年の仕事でかかわったいくつかの現場で、PHPが書けるエンジニアを探してる場面で、PHPは書けるけどフレームワークを使った経験がないという方が意外と多かったということと、フレームワークを使った経験がある人が見つからなくて困るという話をあちこちで伺ったりしたからです。

なので、PHPをはじめたばかりのひと、これからはじめるひと、PHPは書いているけどフレームワーク喰わず嫌いなひとをターゲットにしたゆるめの内容です。なので、ガッツリSymfonyをハックしてやんよ。という人には向きません。

いちおう今日のアジェンダは以下な感じなので、もし興味があれば、途中からでもお読みくださいませ。

  • そもそもフレームワークって
  • じゃあ、どのフレームワークがよいわけ?
  • symfony 1.xとSymfony 2は別物です
  • せっかくだからソースも読もう

そもそもフレームワークって

日々、なんらかのフレームワークを使ってプログラムを書いている人にとっては当たり前のことですが、そもそもフレームワークってなんでしょうか? たとえば、「フレームワーク PHP」とかでググると、ちゃんとした説明は出てきますが、フレームワークって何? という人にとっては、よくわからない解説も多いのではないでしょうか?

「フレームワーク(framework)」とは「枠組み」といった意味の言葉です。実際にはプログラミング以外の多くの場面で使われる言葉なのですが、今回のエントリでは「アプリケーションフレームワーク」、「Webアプリケーションフレームワーク」などと呼ばれるものを単に「フレームワーク」と呼ぶことにします。

PHPで使われるフレームワークにも、「CakePHP」、「Symfony」、「Zend Framework」、「CodeIgniter」などさまざまなものがあります。筆者もすべてのフレームワークを見たわけではないので、なんともいえませんが、PHPのフレームワークは基本的にPHPで書かれています。つまり、既存のフレームワークがなくとも、PHPそのものが書ければ、同じ目的のものがPHPだけで書ける、ということにほかなりません。

実際、筆者の経験の中でも、既存のフレームワークを使わず、自分たちで作った「フレームワーク的なもの」を使ったプロジェクトもありました。もちろん、まったく「フレームワーク的なもの」を作らず、使わずに書くこともできますが、それをしないのは、長い目で見れば効率もよくないし、メンテナンス性に劣るからだといえます。

多少PHPでプログラムを書けるようになった人ならわかると思いますが、もっともシンプルなPHPを使ったサイトの場合、各ページごとにPHPのファイルを作り、それぞれの中で、フォームの入力値をチェックしたり、データベースへの接続をしたり、CSRFやXSSなどのセキュリティ上の脆弱性がないような対策といったことをすると思います。でも、ページが数ページになった時点で、これは効率がよくないことに気づきますよね?

たとえば、データベースに接続するための情報ですら、それぞれのページのPHPに記述されていて、接続先の情報を変えるためにはすべてのファイルを変更する必要があります。もちろん、その中でやっている個々の処理も似たようなものが多く、Webアプリケーション作る場合には、どんなサイトであっても必要な共通の処理が沢山あることに気づくと思います。

さらに、デザインを決めるHTMLの記述とプログラムが一体化しているので、デザイナーさんにデザインだけお願いするのが困難である状況をどう整理すればいいかという問題にも直面するでしょう。

フレームワークは、たとえば、あとから変更したいであろう設定内容をちゃんと設定ファイルとして分ける仕組みや、多くのプログラムで必要になるだろう共通の処理を使いやすい形で提供してくれたりします。また、見た目とプログラムのロジックをどう分けるかなどの全体の「設計(デザイン)」についても一定のスタイルになるような枠組みを提供してくれるのです。

イチから自分でフレームワーク的なものを作ってもいいのですが、すでに多くの先人が試行錯誤したなかからできてきたものですから、それを利用しない手はありません。ですから、これからPHPでプログラムを始めたいという人には、なんらかのフレームワークを使ってプログラムを書くようにすること、を目標にしてほしいと思います。最初は「そうはいうけど、なんでフレームワークっているの?」と思うかもしれませんが、使い続けるなかで、どっかで納得できる瞬間が訪れることと思います。

じゃあ、どのフレームワークがよいわけ?

これは難しい質問ですが、筆者自身、すべてのフレームワークを使ったわけではないので、残念ながら明確な答えを持ちあわせてはいません。

最近個人的に関わっているPHPを使ったプロジェクトでは、CodeIgniterを使うことも多く、「CodeIgniterを読もう。CodeIgniterカンファレンス2011でプレゼンしました」なんていうこともしているくらいですが、仕事ではsymfony 1.x系、最近だとSymfony 2を使う機会もぼちぼち増えてきました(おっと、仕事案件でもCodeIgniterを使ったものはいくつかやってます=追記)。

そのなかで、どれかということになると、それすら難しいのですが、ひとまず「symfony 1.x系」はオススメしません。これは、symfony 1.x系がダメとかいうわけではなく、Symfony 2と1.xではまったく別のフレームワークであることと、symfony 1.4でも来年2012年中にはサポートが終了するためです。

では、CodeIgniterかSymfony 2かというと当然、これも難しい問題です。CodeIgniterはシンプルで学習コストは低く、本当に最低限の枠組みしか用意されておらず、使う側に判断が任されている余地がかなり大きいのが特徴です。一方の、Symfony 2は比較的複雑で学習コストは高めではあるものの、機能は充実しており、フレームワーク自体がアプリケーションのデザインの方向をきちんと枠にはめてくれることで、大人数がかかわるような開発現場であっても対応しやすい設計になっているという印象です。

まったくキャラクタが違うそれぞれのフレームワークですので、適している場面は異なってきますし、もちろん好みなどもあるでしょう。どんなフレームワークでもそうですが、あるフレームワークに慣れているプログラマであっても、他のフレームワークを使えるようになるには、それなりの学習コストが掛かってしまいます。それも考えると、フレームワークの選定というのは非常に難しい問題です。

symfony 1.xとSymfony 2は別物です

Symfony 2では、PHP 5.3以降で利用できる名前空間のサポートや、DIコンテナの採用など、よりモダンな設計でプログラムを書くことができるようになっているなど、symfony 1.xとは、まったく別物です。別物すぎて、筆者も最初にSymfony 2を見た時には驚きました。

また、symfony 1.xでは、標準ではテンプレート自体は、ただのPHPのプログラムでしかなく、これがデザインの修正を難しくしていた部分があります。実際、筆者が相談を受けたsymfony 1.0で構築されたサイトのデザインリニューアルでも、300ページほどあるテンプレートの変更をどうやるかが問題になっています。PHPがわかる人ではないと変更は容易ではないからです。

Symfony 2では、標準でTwigというテンプレートエンジンが提供されていて、テンプレート中に直接PHPのコードを書くことがなくなるので、そうした問題に比較的対処しやすくなっています。Twigのタグ自体は容易に拡張できるようになっているので、個々の案件に応じて必要なタグを追加することもできます。

やはり標準で対応しているAsseticを使うと、複数のCSSやJavaScriptのファイルを1つにまとめて、HTTPのセッションの数を減らしたり、YUI Compressorを使ってさらに帯域を抑えるといった、現実的な問題に対応する手段が提供されているのも魅力的です。

そしてなにより、symfony 1.xに比べて、大幅に軽量化が進み、高速になっているので、これまでsymfonyを敬遠してきた人も、ぜひ試してほしいと思います。

せっかくだからソースも読もう

CodeIgniterカンファレンス2011でのプレゼンテーションでは、CodeIgniterのコンパクトさを特徴に挙げ、コンパクトだからソースを読んだほうがいいとお勧めしました。Symfony 2はCodeIgniterに比べれば大きなプログラムですが、いずれもすべてPHPで書かれているので、PHPがわかる人なら読み解くことは可能です。もちろん、PHPを勉強中の人にとっても、他人が書いたコードを読むことは勉強になりますし、そのフレームワークの流儀もわかるのでお勧めです。

また、ソースを読むと、たとえばAsseticで複数のJavaScriptファイルをまとめたときのURLがどういうルールで生成されているかという、ドキュメントには書かれていない情報も得ることができます。アプリケーションを書くうえでも、Symfony 2自体に足りない機能を拡張していくうえでも、ソースを読むのは多いに役立ちます。

これまでだったら、ドキュメントを読んでもわからないし、とりあえずメーリングリストで質問するしかないかな、と思うような場面でも、ソースを読めば自己解決できることもあるでしょう。もちろん、最初から質問しないで自分でソースを読むべきとは言いませんが、ソースを読むことができれば、自分でも解決できるんだ、ということは知っておいてほしいと思います。

とはいえ、闇雲に読み進めるのは辛いものです。たとえば、エディタのVimとctagsを使えば、関数やクラス、メソッドの定義を簡単に追いかけていくことができるので、そうしたツールを用意しましょう。これは、自分が書いたプログラムをメンテナンスするときでも、非常に役に立ちます。「ctags vim」でググってみるといいでしょう。Vimはちょっとという向きなら「Eclipse PDT (PHP Develpment Tools)」や、筆者は使ったことがないのですが、「NetBeans IDE」にも、メソッドなどの定義元にジャンプする機能があるので、そうした統合環境を使うのもオススメします。

残念ながら、まだまだSymfony 2に関する文書(特に日本語のもの)は不足している状況ですから、ソースを読んで得た知識を文書の翻訳やブログの執筆などで共有していきましょう。

もし、このゆるいエントリで、Symfony 2に興味を持たれたなら、ぜひSymfony Advent Calendar JP 2011の各エントリを読んで、深く深く足を踏み入れてほしいと思います。


トラックバック

このエントリーのトラックバックURL:
http://blog.project92.com/mt4/mt-tb.cgi/107

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

Profile