cakePHPからRubyonRailsに乗り換えた三つの理由

早速の二回目エントリを書く事になった横沢です、お世話になっております。

先日書いたエントリですが思っていた以上に議論を呼んでしまい、且つ違う文脈で書かれている他所様のブログエントリでタイトルが引用されていたりしていたのでしっかり理由と考えを書いておきたいと思いました。

まず最初に、釣り気味のタイトルをつけたせいで不要に煽った感じになってしまったという事、更にはてぶコメにありましたがcakePHPを支える人々に不敬であるという突っ込み、この点に対しては素直に謝罪したいと思います。申し訳ありませんでした。

それではcakephp2.xを採用しない理由について書きたいと思います、大きく分けて三つあります。

1.モデルが配列で返ってくる cakePHP3の開発チームが自ら言ってる通り、2.x系のORマッパーやモデルの作りは一線級とは言えず、現在においては最適解とは言えないと思います。特にエンティティについては個人的にかなりキツイいと感じております。一度エンティティがオブジェクト化されているフレームワークを使うと、配列エンティティのデメリットばかりが見えてメリットが見えないと感じました。 開発当初は「よーし、おとうさんモデル周りをラップしてモダンにしちゃうぞー」なんて張り切っていたのですが短期間では無理ゲーでした。codeigniter並みに軽くて薄いフレームワークならそういう事もやりやすいのですがcakePHPはそれなりに機能豊富で重さがあるので、フレームワークそのものへの理解が浅い人間がさくっとやるには厳しいと感じました。

2.パッケージ管理が雑多 これはcakePHP固有の問題というよりはphp全体に言える事なのですが、パッケージ管理のベストプラクティスが中々まとまってきません。rubyでいうgemsやobjective-cでいうcocoapodsなんかのような仕組みを期待していると、そんな感じにはいかないよ!という事が起こります。こんな事を言うと「composer使えよばーか」とか突っ込まれると思いますが、自分でやってみた範囲ではインストール自体はcomposerで行えても結局はgit submoduleとしてバージョンを管理しなくちゃいけなかったりして前述のgemsやpodsに比べるとかなり煩雑であると感じていました。

3.cakePHP3の登場が来年初頭、ひょっとすると年内も? 最大の理由がこれです。開発チームが言ってる通り3については2.x系への後方互換を大幅に排除されると思います。そんな状況で今2.x系で作って来年辺りに3へバージョンアップしよう!となったら技術的にも時間的にもそれなりに苦しむ事は火を見るより明らかです。

他、個人的に感じた細かい理由を挙げると、 mysqlの型に上手く対応していない、例えばenumはそもそもサポートされてなかったりtinyint(1)を利用するとクセのある挙動をしたりする事。 テンプレートエンジンを活用しようという気があまり無いのだろうか、viewにおいても盛大にphpコードが書かれてしまう事、smartyを導入しようと思ったのですが、配列引数を多用するcakePHPとは相性が悪すぎて断念しました。 等という理由がありました。

今回2.xを採用しない最大の理由となったcakePHP3ですが、1の問題は既にアルファ版で解決されており、2についてはどうなるか分かりませんがcomposerに収束していくのだろう、という期待はあります。またtraitを凄く活用しているという事なのでcomposition over inheritanceが強化されコード資産を再利用しやすいデザインになるのではないかと個人的に期待しています。

そして最後にrailsを採用した理由ですが、railsは現時点でこれらの問題を全てクリアしており、4へのメジャーアップデートも行ったばかりで今日においては最も力のあるフレームワークの一つであると判断したからです。また、本プロジェクトをお手伝いして頂ける外部開発者の方が、すばらしいrailsの知識をお持ちという事もあり最後の踏ん切りがついたという流れです。つまり結局はタイミングの問題でしかなくて、言語の優劣がどうとか、フレームワークの優劣がどうとか、といった観点は殆ど無く選びました。

当初は「symfony使えばいいじゃない」とか「Laravalがアツいらしい」とか「個人的にはcodeigniter激推しです!!(これが私の当初意見です)」とphpフレームワークが挙っていたのですが、この辺も実は使う側にとっては頭の痛い問題であると感じました。phpはしっかりとしたフレームワークが既に数多く存在し、毎年のように新しいフレームワークが生まれていきます。この動き自体は悪い事だとは思わないのですが、使う側からすると中々一本化できずに困る事もあると考えています。その点railsrubyにおけるフレームワークのほぼデファクトスタンダードになっており、rubyコミュニティの力が分散していないという点も採用理由の一つになったと思います。

という訳でイタンジでは言語やフレームワークを柔軟に活用してサービスを進化させてやるぜ!というエンジニアを募集しております。