皆さん、こんにちは。ポケモンGOにハマって普段いかに運動していないかわかった寺井です。
このコラムも無事第二回を迎える事ができました。
今回はPHPのフレームワークについて持論をガッツリと展開していきたいと思います。
アジェンダは以下の通り。
* フレームワークの基礎知識
* どのフレームワークを使えばいいの？
* フレームワークを使用するメリットとデメリット
* 一つのフレームワークに固執しない
前回の内容と多少被る部分がありますがご了承ください！
フレームワークの基礎知識
PHPのフレームワークとは簡単に言えばテンプレートの集合体です。アプリケーション上でよく使われる機能の土台がまとめられています。
オープンソースのものはコアデベロッパーだけでなく世界各国の人々が必要と思われる機能を追加し日々進化を続けています。
昨今の開発現場で完全なスクラッチ開発の現場は０ではないですがだいぶ少なくなっているのではないかと思っています。
既存のフレームワークを使用していない所でも、開発現場独自のライブラリ（よく言われるオレオレフレームワーク）を持っていると思いますし
そういったものがないとしても部分部分で過去のコードをincludeして使用してるはずです。
ただし、オレオレフレームワークの欠点として分業する場合や部分的に外部委託するときにドキュメントが充実出来てないことが多く苦労します。
また、熟練の職人以外はセキュリティがフレームワーク内に存在するレベルに到達してないことが多いと思います。
そして今から作るぞ！となっても完全なスクラッチ開発からはほぼ丸々車輪の再開発を行うことですから業務としては致命的な効率の悪さですよね。
自前のライブラリを持っていない状態からスタートするときにはやはり**既に動作が検証されている土台**を利用したほうが開発効率やメンテナンス性はあがるわけです。
PHPフレームワークの動作の簡易な一例を画像にしてみました。
MVCが絶対に必要ではありませんが、最初のうちは機能を丁寧に分類してシンプルなコーディングを心がけたほうが、
後々の応用に生きると思います。
どのフレームワークを使えばいいの？
今回のコラムではどのフレームワークがおすすめか？といった具体的な指定は避けたいと思っています。
と言うのは、フレームワークの種類は日々増えていっていることもあり、現時点でベストと万人が思うものでも数ヶ月すれば新しいバージョンが出たり、開発が停止したりしてしまうこともあります。
もし皆さんがどのフレームワークを使ったら良いか迷ったときは、その時点で比較をしているサイトを探してみたりGoogle Trendsでフレームワーク名を比較してみたら良いでしょう。
個人的には、最初に触るフレームワークは日本で流行っているものに絞ると良いと思っています。
理由は簡単、周りに知ってる人が居て直接質問する機会が多くなると考えているからです。
そして一つに決めて使い始めた後もトレンドは常に追いかけておいたほうがビッグウェーブに乗り損ねることも減ります。
ある日開発が終了してたりしてたら目も当てられません。
フレームワークを使用するメリットとデメリット(初心者として)
前述したとおりオープンソースフレームワークにはアプリケーションの土台が準備されています。
ですのでフレームワークを使用した場合、自ら記述するコード量自体はかなり圧縮された状態になります。
ですが実際に結果として出力される情報にはその数倍の処理が施されています。
セキュリティ面に関して言えば特に意識をしなくとも、必要最低限の土台は存在してはいます。
ただし本当に最低限であり、そのほかの機能の組み合わせによっては逆にセキュリティホールを自ら開けてしまうことにもなりかねません。
メリットとして、一から全てを作る労力や、前回のユニークIDの生成のような必須ライブラリの作成コストが削れ、動作が保証された状態のものが多々ありますが、
デメリットとしてはその動作がどういった工程を経て結果に至っているのか理解しないままでも希望する動作まで到達してしまうことです。
これはありえない話ですがフレームワーク内に隠されたセキュリティホールを作られていてもソースコードを見るコストを省いてしまうと、
それに気づかずに動作させてしまう事にもなるわけです。
デメリットと書きましたが逆に言えばこの部分を補強すれば自らの技術の前進に繋がるわけです。
バージョンアップを重ねてきたフレームワークのソースコードは先人の大いなる知恵が凝縮され日々洗練されてきたコードな訳です。
このソースコードを読む行為はフレームワークをただ単に使える様になるのに比べ、多大な学習コストが発生します。
開発現場で時間を割くのは大変だとは思いますがライブラリを利用する毎に少しの時間ずつでも割いてみてください。
それが **使われる立場から使う（さらに言えば使いこなす）** への転換です。
一つのフレームワークに固執しない
多種多様なオープンソースフレームワークが存在する現在、ある程度は使用するフレームワークを絞る必要があるでしょう。
そしてそのうちに一つのフレームワークを深く学習していくことになると思います。
あるいは自らの手でオレオレフレームワークを組み上げる方もいるかもしれません。
はじめは一つに決めて一つを掘り下げる *浅く広く* ではなく**狭く深く**したほうが実用性は高いと思います。
私自身がこの意識で今まで過ごしてきたのですが【他のフレームワークを学ぶタイミング】を逃してしまうと、
フレームワーク指定がない限り用途規模問わず同じフレームワークで作ってしまうのです。
これは単純に費やした学習コストから得た開発速度の問題です。
「サクサク書けるからこれでやっちゃえ！」となるわけなんですがそのままだと新規に学習するコストと開発速度が見合わなくなる。
結果なかなか業務に新しい技術を投入できないスパイラルに陥ったり、なかなかバージョンアップに伴うマイグレーションをできなかったりします。
新しい技術・フレームワークは常に追いかけ、ある程度一つを深く学んだら次を探してまた学ぶを繰り返すとより一層技術の研鑽が進むと思います。
現在人気のあるフレームワークはRuby on Railsをモチーフにしているものが多いですので、全く別の言語に乗り換えるよりは幾分とっつきやすいはずです。
独自の規約があるので全く苦労がない訳ではないですが、初回のフレームワークで学んだことが確実に生きてきます。同じPHPですからね。
そして新しいフレームワークを学ぶことによって「このフレームワークは規約に縛られすぎる！」や「こっちは自由すぎて結果ごちゃごちゃなコードに！」と
様々な問題点が浮き出てきて最終的にオレオレフレームワークに行き着くということも一つの正解だと思っています。
PHPという世間的に簡単と言われている技術でも一つの視点からではなく多角的に見ることによって新しい見え方を味わえるはずです。
以下の画像はCakePHPとLaravelをコマンドでapplicationフォルダを生成したものです。
同じPHPで最近流行りの2つですが片方を完璧に理解していてももう片方を即座に100％のパフォーマンスで動かすのは至難の業です。
まとめ
* フレームワークとはアプリケーションの土台を提供してくれるものである。
* 簡単に動いてしまうからこそ、その中身を知るべきである。
* 多角的にみることによって本当に自分に合うフレームワークを見つけよう
いかがでしょうか、コラムと言うものに筆者自身がなれていないため自問自答しながら記事を作成させていただいています。
皆さんがこの記事を見て自分に合ったフレームワークに出会うことができれば最高に嬉しいです。
気になる点や指摘すべき点などが有りましたらご連絡いただけますと幸いです。
次回は開発環境(主にIDE)についてお話できればなと思います。
