【決定版】PHPフレームワークのデメリットまとめ

Tweet

PHPというWEBで良く使われるプログラミング言語とそのフレームワーク（スクリプト全体の土台になる抽象化された機能を集約したもの）のお話です。
巷のサイト上にはPHPフレームワーク（Codeigniter、CakePHP、ZendFramework、Symfony、FuelPHP等）推奨の情報がたくさん出回ってますが、そんなに良いものならもっと広まってるはずでしょ。。
フレームワークが良いものかどうか、普及具合で結論でてるのに、「善し悪しを理解して上手く取り入れましょう！」みたいに推奨してるサイトの多いこと。。

ということで、普及が進まないのに、一部の人に人気のあるフレームワークのダメだしをしてみます。

①メリットを否定してみる
フレームワークのよくあるメリットを否定してみます。
フレームワーク使わなくても少し考えればできることを、フレームワークのメリットとして紹介していることの多いこと。。

(1)早く作れる（開発が効率化する）

そうなるには、1週間くらい、カチで使い方を勉強する必要があります。（言語の理解がある前提で）
折角覚えたと思ったら、細かいところに手を入れようとすると、調べるのにすごい時間がかかるし、意味も無く重たく動いたりすることがよくあります。
（フレームワーク様が用意してくれてる機能が今回の実装の合わないので、内部のソース弄っちゃいますねー仕様を実現しないといけないんで。。なんてことはよくあります。抽象化されすぎてたり弄ったら影響範囲読めない場合は独自に処理作っちゃいますよってなって、結局ごちゃごちゃに・・）

使用するフレームワークによって差はありますが、フレームワーク使わないで作るより軽くなることはないです。

実際は、フレームワークで簡単にできることだけ組合わせて重くても動けばいいって状態で完成できるなら早いかもしれないくらいです。

で、作ったはいいけど、保守はどうするの？？そのフレームワーク理解してる人しかできません！！環境もフレームワークのバージョンにあわせて用意しないと！ってなります。。WEBだからPDCAまわしてかないといけないのに。。

「保守がしやすい」ってメリットうたってる場合もありますが、あくまで、"そのフレームワークを理解してる人が、最適な環境で”って前提がつきます。（使ってないと保守できない。。）そういうことは、どれかのフレームワークがPHP標準実装になって、世界中で使われる前提になってから言ってもらいたい。。

(2)バグが発生しにくい

中身がどうなってるか分からない用意された（どこかの優秀な人が作ってくれた）機能に値渡すだけなので、自分で書いてスペルミスしたり、穴のあるプログラムを書いたりすることが少なくなるということですが、そもそもプログラミングとは、自分で考えて自分で書いて、バグがあれば自分で直すものです。で、力がついてより良いプログラマになってゆくのです。教科書に書いてあることをなぞるだけではいつまでたっても自立できません。

フレームワーク内でひとたびバグが発覚すると、大変なことになります。自分では治せない（不可能ではないけどすごい大変）し、フレームワークをアップデートすると他の場所が動かなくなるし。。

「脆弱性が突かれにくい」というメリットを謳ってる場合もありますが、ハッカーからすれば、フレームワークの脆弱性見つけられれば、それを使ってるサービスまとめてハックできるので、モチベ高いです。

「用意されている機能が世界中でテストされている」というのも良く見かけますが、実際ガチでテストしてる人は少ないし、ボランティアだから、その機能を作った人がいつのまにかいなくなってる場合もあります。使ってる人数をテストしてる人数とは言えないでしょ。。

(3)コードの書き方を統一させることができる

そもそもそんなに人によって書き方違わないし、よほどごりごり書いた大きなシステムでない限り追えば分かります。追うのに時間がかかるといってもたかが知れてます。

フレームワーク使うと、フレームワークのルール通り書かないとはねられる（エラーになる）し、なんのエラーかもわかり難い状態でストレスになります。推進派はきっちりフレームワークを勉強してる前提なので気にしないみたい。Zend2とか終わってるくらい情報なくて解決大変なのに。。
普及しなかったり短命で終わるフレームワークの情報は海外のサイトに頼ることになります。

コードの書き方が統一されているということは、外れたことを書いてはいけないということでもあり、自分の実現したいことができなくなる場合まであります。
（縛りプレイ強要されます。仕様を設計する人はWEBのことは分かっていてもフレームワークの仕様まで知らない訳で・・）

良く似た主張に、「コードとテンプレートを分離できる」というのもありますが、そんなのはフレームワーク使わなくてもできるし。。

「コードがシンプルで見やすくなる」（フレームワークは自動でHTML要素やSQLを生成する機能がある）というもの同じです。作り方の問題であって、フレームワークかどうかは関係ない。。WEBの場合はHTMLのタグとか、SQL文とか、なんでも簡略化できれば良いというものでもない（改修の頻度が高い）し、長くてもちゃんと追える人は追える。エディタの使い方や追い方を覚えるべき。



②本当のデメリット

(1)学習コストがかかる以上の見返りがなく、保守する人に負担がかかる。

自分は選択したフレームワークが最善だと思ってるかもしれないが、皆は違うフレームワークや、使わないことが最善だと思ってたりします。

今後ずっと自分しか見ないコードなら良いですが、人が見るかもしれない、仕事のプログラミングなら、自分の考えを主張するばかりでなくて、周りをみるべきです。

自分で書いてバグばっかりになったらどうしよう↓とか、脆弱性突かれてたらどうしよう↓とか、経験してスキルアップすれば万事解決です。

フレームワークによっかかって、バグや脆弱性の本質をいつまでも理解しないつもりなら、WEBのプログラミングやってる意味ないです。


●おまけ

フレームワーク推奨してる方は、専門書籍を売りたいとか、邪な考えではなく、純粋にいいものだと思ってるから難しいです。自分はそのフレームワークと心中するつもりだから良いのかもしれませんが、そうやって各自が違うフレームワークに突っ走るから、動作が読めないスクリプトが氾濫するのです。。
Googleのエンジニアみたいに必要なライブラリは自信をもって自分でつくるようになると良いのですが。。


【2015/11/17追記】
コメントとたくさんのいいね！ありがとうございます。
PHP自体は割と誰でも少し勉強すれば書けるようになります。（CとかJavaとかと比較して）
そういう人が上達する過程では、フレームワークのようにブラックボックス化されて、（初心者にとって）流れも追いにくい物を使用するべきではなく、まずは自分で整理されたソースを書けるようになるべきです。
未熟なソースは誰かに指摘（レビュー）されて上達する糧になります。

「オレオレで好き勝手は保守できない（バグる）」は良く聞くフレーズですが、よほど独自のロジックで作り込んでいなければそんなことはないと思います。（クセとかはあるけど流れとして把握できないことは少ない）

「ユーザもナレッジも多い」も良く聞きますが、フレームワークによってすごい差があるし、すそ野の広いPHPプログラマ全体からすると、どれ使っても一部の人になってしまうと思います。（ちょっと乱立しすぎですね。。）

最後に、分かりやすいように順位付けだけしておきます。

オレオレと言われるかもしれないが、イケてるソース（シンプルで流れも分かる！）＞＞　オレオレかもしれないし、ちょっとイケてないソース（頑張った感はある！）　＞＞＞　ドキュメントあるから一応オレオレではないとされているフレームワーク達（どこまで乱立する気？）　＞＞＞　ドキュメントが少ない（日本で）マイナーなフレームワーク達（Zend2とかCake3とか）　＞＞　オレオレフレームワーク極み（独自のロジックに没頭しまくり）

CakePHPで学ぶ継続的インテグレーション【電子書籍】[ 渡辺 一宏 ] 価格：3780円 (2016/11/10時点)

Zend Framework, 2-Volume Set: The Official Programmer's Reference Guide [ 0. Zend ] 価格：14722円（税込、送料無料) (2016/11/10時点)

基本からしっかり学ぶSymfony2入門 [ 後藤秀宣 ] 価格：3456円（税込、送料無料) (2016/11/10時点)

Comments

[18. A]

確かに！！FW使う前に本質理解しろってPGが沢山。

[17. しがない男]

かなり前の記事だけど、このテーマは自分も思うところがあるのでカキコします。
自分がフレームワーク使う場合は以下のケース。
・勉強のため
・フレームワークのソースコードを全部把握している場合。

１０年くらい前だけど、自分はMVCの概念学ぶのにCakePHPがかなり役に立ちました。独自にフレームワークを作成するときもCakePHPの記法を参考にしました。
だけど、実際にサービスを作るときはフレームワークを使うのは好きじゃないかな。というより、フレームワークでできることは大体自分でも書けるから。
よくフレームワークを使えば書き方を統一できるってあるけど、それはチームでコーディング規約を決めたり、MVC、デザインパターン、オブジェクト指向について、意味だけでなく実用レベルで扱えるメンバーが揃ってれば、そんなに変な書き方にはなりません。むしろフレームワークをたくさん使ってる方がスパゲティコードになってることが多い。
セキュリティを担保できるっていうのも微妙で、基本アプリケーションレイヤであればインジェクション対策、XSS、セッションハイジャック対策、etcといったことを押さえておけばよくて、逆にフレームワークを信用しすぎて内部処理を理解してない方が知らないセキュリティホールがあったりする。


外部のモジュールを使う場合って「ブラックボックス化」って考え方があるけど、フレームワークの場合はブラックボックスではないんだよね。なにか問題が起きた時や、特殊な処理を入れる場合にソースコードを追ったり、時には拡張しないといけない。フルスクラッチで書くと、（ちゃんとリファクタリングしてれば）最低限の汎用化しかしてないから処理や影響が追いやすい。
だから、フレームワークを使う場合は、ブラックボックスで考えてはダメで、完全にホワイトボックスにできるときしか使いません。でも、そうすると大体自分で書いちゃえってなる矛盾、、、。

[16.]

お前ら元気だな。
Excel使え。

[15. test]

小規模であっても自分でライブラリ作り貯めてそれを改良していけば良いという結論に達しました。ありがとうございます。
ネガティブなコメントしている方々は何故そういうコメントになるのか行動原理が理解できず苦笑しました。

[14. なかじま]

私もZFやCakephp1.2でいくつか作りましたが、私のように小規模で1人で管理するものには全くメリットがなく、それ以来オレオレで組んでます。
規模が大きくて複数人で組んだり管理するんだったらいいのかもしれませんね。

[13. メソッドマン]

本当にそう思う。フレームワークに没頭すると、様々な技術の核の部分が隠されてしまうため、プログラムの本質を見失うような気がする。

[12. あｓｊｆｄｋｌｊｆ]

現在、CakePHP2使ってるけど、

単純な処理なのに
オッセー！！！！！
そして、コードが冗長すぎる！！
そして、ドキュメント不足なので、把握できないことが山ほどある。


死ねよゴミフレームワーク

[11. あらつき]

最後に、

フレームワークを利用していても、
結局のところカオスになってしまうのがプログラムです。


フレームワークの制約に対応するためにむしろコードが増えてしまうという例が頻発しています。

これでは、フレームワークの意味がありません。



＞「フレームワーク使わないで組んだあなたのソースを保守するほうがよっぽど大変なんじゃないかな。」

というような、詭弁がましい文句に惑わされすぎだと思います。

フレームワークで組んだソースを保守する方がよほど大変だと思います。
自分だけフレームワーク知ってても、「無駄に複雑にしやがって」と逆に煙たがられますよ。フレームワークなんて誰も勉強する時間も無ければ資料も例も無いと怒られてしまいます。


ちなみに、私は、Symfony、Cake、Ethnaなどを参考に、
社内独自のフレームワークを開発しました。

既存のピュアなPhperを取り込むために、わかりやすいドキュメント、
わかりやすい構造にして、もちろんオブジェクト指向、MVCで実現しました。ビューはSmartyでした。
また、誰もが使ってる表計算ソフトにGUIを作って、CRUD構造のコードをジェネレートできるようにしました。

これにより、学習コストはCakeを覚える、1/30くらいの費用に抑えることができました。パフォーマンスも良いです。

どのようなフレームワーク人材にも対応できるように、ピュアなPHPが採用の最低条件としました。結果、良質の人材も集めることにつながりました。

[10. あらつき]

＞1

実際にさして力の無い人でも他者の書いたプログラムは読める。
ある程度の構造化さえされていればだけど。

もし、懸念があるなら、設計書をしっかり書いておけば、設計書を読める人であれば、すぐに理解できる。
たとえば、基本情報とか初級シスアド　クラスの勉強を合格させたことのある人であれば、
すぐに設計書の意味がわかるし、ある程度は書ける。


もし、設計書も書けないし読めない、プログラムも読めないならそれは、
そいつにプログラミング能力も、デザイン能力も無いということ。
フレームワークを利用しなければならない層はまさにそういう底辺層が大量に要るからだ。

そして、底辺層は戦略もなければ分析も無い、
より上流工程のことなんてまったくわかってない。

フレームワーク人材を集めたり教育するよりよほど、コストが安いし簡単なことだ。
PHP7への移行もしやすいしね。




　なんにしても、供給力の低下は、フレームワーカーにはトドメのような自体でしかない。
だからこそ、Railsに注目が集まる。ただし、Rubyはすでに主要なフレームワークは3つになっていて
PHPほどではないが、分派が始まっている。
ただし、現行ではPhperからRuberに流入人材も増えているから、供給力の低下が起こっていることが実感しづらい状態にある。
いずれ、Ruberの流入が停滞すれば、Rubyフレームワークの分派に翻弄されて供給力は低下の一途をたどるだろう。
いずれ、PHPについては、いずれスタンダードなフレームワークが開発されるだろう。
それは、Rubyより早く需要が訪れるだろう。

[9. あらつき]

私もフレームワークはベンダーロックインの温床としか言いようがない。
フレームワークに惑わされる人は、情強とか情弱とか関係なく、ベンダーの広告戦略に弱いだけだと思うね。

フレームワーク・ベンダ側から見たら、そのフレームワークの導入がいかに効率的で役に立つかばかりを宣伝するけど、
フレームワークのデメリットをほとんど説明しない。

フレームワーカーは、フレームワークについての本当の知識を知らない。


たとえば、IPAの国家試験(システムアーキテクト)なんかでもフレームワークの問題点を聞かれる。
学習コストや保守コストとして本当に最善な選択なのか、どうやってそれを決定付けたのかを、アーキテクトの立場で答える出題もあった。

その際に、本当にフレームワークベンダの宣伝文句を、解答として論述するのか？

はっきり書こう、一番、問題なのは、いくつにも分派したフレームワークがあるから、開発力の総量すなわち、供給力においては著しい低下をしているように思える。

だから、IPAの試験でもフレームワークについてはスルーされている。
標準化とは逆走するものだから。

フレームワークはスタンダードでもなければポピュラーでもない。
マナーでもなければルールでもない。

フレームワークを推奨する人は、力の無い人だと思うね。
戦略も分析も無い、ただ広告に惑わされて格好付けの見栄を必死に張る人に思えるね。

一応、当方、15年のPhper歴があるが、圧倒的にピュアなPHPの方が開発供給力が高いと確信している。何度もフレームワークは学習したし導入もしたけど、手探りが多すぎるし、分派しすぎて人材も集まらない。

[8. あああ]

1つのフレームワークが1週間どころで習得できるわけない。
教科書に書かれるように動くかどうかなんてわからないし。
教科書は中途半端にばかり書かれていて途中で説明が途切れているものばかりだ。
完全に説明不足だし、完璧なドキュメントなんてどこにもない。
よくいるエンジニアの見栄みたいで見苦しいブログだ。
簡単なんて書いたらその分、別分野で仕事をするIT素人から見たら過小評価されるんだよ。

作った側の人間だって、1年とか半年は必ずかかると説明している。

[7. 元PG]

否定してる人たち冒頭の文章理解してんのかな。
これだけ何年も乱立が続いてるってことはPHPはフレームワークを作るような言語じゃないってことだよ
PHPの本当の利点はスクリプトであること、Perlよりも可読性に優れ、さくっと作って、さくっと作り捨てができること。
腰据えてメンテしなきゃいけないような開発にPHP使うのがそもそも間違い。

mojaviから始まって、5年いろんなPHPのFW使って
俺が出した結論。

[6. あうあうあ]

phpに限らないんだよなぁ

[5. てす]

この人が作った、この人の頭の中にのみマニュアルがあるFWと、
Webにきちんとドキュメントがあり、ユーザもナレッジも多いFW、
どっち使いたい？

前者選ぶような人とは仕事したくないね

[4. 774]

> Googleのエンジニアみたいに必要なライブラリは自信をもって自分でつくるようになると良いのですが。。
最後にこれを付け足している意味がわからない
中の人ではないが、結局あなたが言っていることとさほど遠くないことが起こっているんじゃないかと、私には思える。

[3. 名無し]

１さんの言う通り。
オレオレで好き勝手に書かれたソースコードなんて誰も保守したくないよｗ
何か１つのFW習得したら別のを習得する学習コストなんぞ大したことない。EC-CUBEはsilexで書かれてるが１日で理解できたし。

主はFWのソースコードを読むことが苦行と捉えてるようだが、世界の先人達の書いたコードは読むだけでも勉強になると自分は思う。
苦行と思うならこの仕事向いてないよ。早いとこ別の仕事見つけたほうが良い。

[2. みんなrails使えばいいよ]

ダメなのはわかった。で、オススメは？

[1. K]

勉強したくない、と言うことは理解できた。
フレームワーク使わないで組んだあなたのソースを保守するほうがよっぽど大変なんじゃないかな。