PHPフレームワークにCodeIgniterを選んだ理由

  • 58
    いいね
  • 0
    コメント

CodeIgniterのAdvent Calendar 2015 2日目に参加しております。
本年開発に採用したPHPフレームワークCodeIgniter(コードイグナイターと読む)は現在進行形で活躍しております。年末ということで、今年なぜPHPフレームワークに「CodeIgniter3」を採用したのか振り返りたいと思います。
フレームワークを使う・使わない、どのフレームワークにするか検討する際の1事例として参考になれば幸いです。

最初はインハウスフレームワーク作りました。

10年くらい前に最初のPHPフレームワークを作成しました。5人程度でのWEB上の業務管理システム開発、そこそこ規模はありました。インハウスフレームワークいわゆるオレオレフレームワークです。

当時のフレームワーク作成の一番の目的は、プログラマ・デザイナ分担のためにViewを分けることでした。
その後Logging,Validation,SQLBuilderのようなものが増築されました。
このときは、そこそこ処理が複雑だった割にシステム全体の応答性能が良く、サクサク感に高評価を頂き、現在もWEBシステムは利用いただいております。

この時のPHPインハウスフレームワークの良し悪しです。

良かった点 問題
サクサク動くレスポンスが速い。 マニュアルが無い。
新しい開発メンバーに非常に不評。
シンプルなので見ればわかるということでカバーしてる。
知ってるので修正しやすい PHPバージョンやセキュリティ対策に追従していくのが大変。
mysqlをmysqliに変更し、なかなかコワい。
  UNIT Testが書かれていない
ハレーション発見しづらい。
  メンテナンスできる人が減った。

パブリックなフレームワークへシフトしていきます。

だんだんインハウスフレームワークの問題点が負担になってきたのと、とある案件で某社さん作オレオレフレームワークに触れ、膨大・ドキュメント無しで同様な問題を超大規模(コスト的にも)に抱えていたのでゾッとしました。

なので、数年前からパブリックなフレームワークを試しています。案件も含め、試したのはこんな感じです。

CodeIgniter(ver.2系)

数年前に使ってみましたが、へへー、こんなに簡単なんだーと思いました。レスポンスも良いです。
ただ、フレームワーク自体の機能は少なく、処理自体の作りこみはそこそこ必要だなと思いました。認証などは標準ではありません。フレームワークって、CRUD処理や一覧表示やPagerみたいなものを自動でやってくれるのという妄想からはギャップがありました。

CakePHP(ver.2系)

よく設計されているなぁと思ったフレームワークです。規約に沿って作れれば、とってもしっかり作ったものになりそうです。
bakeでのScaffoldingでできるCRUD処理とViewのひな型を見て感心しました。
ただ、この時は1ヶ月しかない開発期間に適用でした。依頼元提示の規約合わないDBが対象だったり、妙な構造のテーブルだったり、とっても相性の悪い案件でした。bakeは不発に終わり、あまりCakePHPの良い所は発揮できませんでした。
個人的に感じたのは、学習コストが高い・規約の縛りが多いことです。SQLをちょっと発行するのにも結構調べ物しました。

cakephp で GROUP BY や SUM,COUNT とかを取る場合のバーチャルフィールド(virtual fields)利用

またレスポンスもなんだかもっさりするなぁと思いました。
チューニングすれば解決するのかもしれませんが、そこまで調べるに至っていません。

FuelPHP(ver.1.5~)

CakePHPよりももう少し規約の少ないものは無いのか、CodeIgniterに戻ろうかと思っていた時に知ったフレームワークでした。
oilコマンドでのmigration,taskなど備え、一応はScaffolding、認証もSimpleAuthがありました。コードの記述もCakePHPほどの規約や学習は不要でした。これは面白いフレームワークだと思ったものです。
ただ、多くのデータを表示する際にもっさりしていたので、調査したことがあります。

FuelPHP1.5.3でViewに渡すデータが多い場合のパフォーマンス ORMとDBでの比較

設定チューニングと、ORM使わないことで、パフォーマンス上がり、サクサク感は出ました。
自由度と機能とバランスよいなーと。

Laravel

ウェブ職人のためのPHPフレームワーク..に惹かれて使ってみたいフレームワークですが、まだ触れていません。

そしてCodeIgniter3へ

今回「フレームワーク?自由にやって。」というPHP案件が来たので今までのことを振り返って選択してみました。
選択肢としては、FuelPHP、CodeIgniter、CakePHP、Laravel、Symfonyあたりです。

掲げた条件としては、
・せいぜい3~5人での案件が多いので大規模向けなものは不要。
・広まっていて情報が多い。
・学習コストが低い。
・ORMは不要。DB変わったり、SQL知らないメンバは居ない。ただ、SQLBuilderは欲しい。
・UnitTestをちゃんとやりたい。
という感じです。最初はFuelPHPのつもりでしたが、CodeIgniter3を選びました。
以下、CodeIgniter3を評価したポイントです。

パフォーマンス

こちらがとても参考になったのですが、CodeIgniter3はパフォーマンスが比較的良いです。

PHP Framework Benchmark

以前もCakePHPがなんかもっさり感があったので、CakePHP,Laravel,Symfonyは候補からはずしました。

見渡しが良い

CodeIgniterのCoreのソースはチョット見ると大体処理がわかり追いやすいです。
ver.2系を触ったこともあり、学習コストは低かったです。
もしcore側に修正したいことがあっても何とかなりそう。また時折依頼元から処理の説明を求められる場合があり、これなら追えるので説明できそうです。

トレンド

日本ではCakePHPやFuelPHP、Laravelが多いようですが、世界だと、Laravelが急伸、CodeIgniterが多いです。
これだけCodeIgniter使っている人がいれば、まぁ利用事例等もあるかなと。ただLaravelは気になる!

phpフレームワークのトレンド2015年 FuelPHPどうなっただろう。

タイミング

  • FuelPHPかCodeIgniterにしようか悩んでいたところ、CodeIgniter3が出ていてMITライセンスになっていました。ver.2の頃のライセンスより解釈しやすくなりました。
  • ci-phpunit-test CodeIgniter 3.0でPHPUnitを使うが登場!JenkinsやPHPUnitと合わせて使ってみるとうまくテスト可能でした。

えいやっ!

最後はカンです。こんなところに後押しされました。

  • CodeIgniter を略すと" CI " = continuous integration 継続的インテグレーション (継続的開発)と錯覚してくれそう。ちょうど、Jenkinsやユニットテストなども取り入れたかったので、ちょうどよかった。

  • しびれる一言
    CodeIgniter3いいなぁ、どうしようかなぁ、と迷っている時に、こんなブログを発見。

Codeigniterでは逆立ちしてもできない!みたいなものはありません。その逆もしかり。
半年使って分かったPHPフレームワーク「Codeigniter」の魅力5つ

これから先は?

Codeigniter3での開発はリリースまであと少しです。
今のところレスポンスのサクサク感を保っています。
Jenkins + ci-phpunit-test のおかげで発生しづらい条件のコードもテストしながら開発が進められています。
依頼元のあやしい構造のDBが来ても処理の記述方法に詰まることはあまりありません。
今回CodeIgniterはウチの開発事情に適合していました。

ただ、CodeIgniterには、便利なライブラリが最初からたくさん揃っているわけではありません。認証など標準ではありません。
しかしCompeserとかを使って必要モジュールを追加して利用すれば良いのです。たぶん。
これらのことを @nanndemoiikara @rdlabo さんに託したいと思います。

では皆さま、よいCodeIgniter年末を!

参考)
- PHP7でCodeIgniterを動かしてパフォーマンス測ってみた
- CodeIgniterのViewで少しだけ工夫した点
- PhpStormでautocompleteを有効にする方法(CodeIgniter3利用時)
- PhpStormで256倍楽しくコードを書く方法(CodeIgniterの場合)
- はじめてのPHPフレームワーク PHP初心者がすぐ現場で活躍するための CodeIgniter3超入門

この投稿は CodeIgniter Advent Calendar 20152日目の記事です。