フレームワーク選びの基準
kunitさんのところから。
仕事でフレームワークを選定する場合は「個人の問題」ではないんです。「チームの問題」「会社の問題」になるんです。
なので、「なぜその仕事でそのフレームワークを選んでるんだ！」という問いは、個人ではなく、チームや会社に問わないといけないわけです。
なので、個人の好みの問題ではないんすよね・・・そのあたりどうもPHPでは個人の好みレベルの議論が多くてまだまだ成熟度がたらんなぁと。
業務で使うフレームワークを「開発方法論とセット」で捉えるべきというのは確かにその通りで、Seasarなんかはその視点を持っていますよね。
かつてのMVCな設計を提供するだけのシンプルなフレームワークだったら好みで選んでも構わない気がしますが、Rails以降のフレームワークは多かれ少なかれユニットテスト、デプロイ機構、データベースマイグレーション、ドキュメント生成といった開発にまつわるあれこれをサポートしていますから、そのフレームワークが前提とする「開発の仕方」、「運用の仕方」が馴染むかどうかは結構重要なところ。
CakePHPやsymfonyもユニットテストやマイグレーションサポートを盛り込んできてはいますが、そのフレームワークでどうやって開発のイテレーションを回していくか、という視点での情報・サポートがあんまりないのが残念です。ユニットテストができればアジャイル開発なのかっていうとそんなことはないので、様々な要素をどう繋いでいけば開発がテンポよく回るのかっていう枠組みまでを提示していって欲しいですね。
などと書きつつ、個人的には「フレームワークのデザイナ(設計者)のセンスを信じられるか」というのがフレームワーク選定の最大の要素であったりします。DHHの言うOpinionated Softwareに共感できるかってこと。あまり合理的ではありませんけどね。