アプリ版:「スタンプのみでお礼する」機能のリリースについて

PHPでフレームワークを使う意味ってあるのでしょうか?
私的にはメリットよりデメリットのほうが多いと思っています

そもそもPHPは便利な関数が元々充実していますし、WEB上に多くの情報が存在します
フレームワーク固有の関数を探してくるより
PHPで実現するソースコードを探してくる方が速いと思うのですが

最近では珍しくないと思いますが
デザイナーもプログラムの知識を持っているチームの場合は
MVCに作業分担するメリットも感じられません

フレームワークをかませることで
不具合発生時の原因の特定も複雑になります

PHPでフレームワークを使う意味について
皆様の意見をお聞かせ下さい


メリット
・MVCに作業を分担できる
・機能が用意されている場合は作業の簡略化が期待できる

デメリット
・フレームワークに脆弱性が見つかった場合に対応が必要
・フレームワーク自体にバグが含まれている場合がある
・不具合が起きた場合に原因の特定が難しくなる
・ノンフレームワークに比べて速度は遅くなる(Phalcon等、例外は除く)
・ノンフレームワークに比べて柔軟性はなくなる(Phalcon等、例外は除く)

A 回答 (8件)

フレームワークを使う使わないの2択に限定する


必要はないのでは?
仮に既存のフレームワークを使わないと決めたと
しても便利な点が1つでも2つでもあったら取り入
れれば良いだけだと思います。
    • good
    • 1

MVCの最大のデメリットは


ちょっと批判すると信者にたたかれることかな

宗教みたいなもんだから、なくても困らないけど
使わないからといって利用者を批判すると戦争になります。
世の中いろんな人がいるんだねとやさしく見守ってあげましょう。

逆に利用者からして推奨したり勧誘するのはいいが
不使用者を全否定するのはカルト教徒レベル
どんなに適切で正しいことを言っていてもかかわりたくない
    • good
    • 1
この回答へのお礼

yambejp様

回答ありがとうございます

>宗教みたいなもんだから、なくても困らないけど
>使わないからといって利用者を批判すると戦争になります。

わたしの質問、フレームワーク使いを批判してるように書いてますかね
そういった意図はないです、すみません。。


>逆に利用者からして推奨したり勧誘するのはいいが
>不使用者を全否定するのはカルト教徒レベル

この手の話は、自身の主体性を保つために攻撃的に出てしまうクラスタがたまにいますね
偉い人でも。。。
私も、クリエイティブは柔軟性を失ったらおしまいだと思います。

お礼日時:2014/07/17 10:52

shylockさんの回答に概ね賛同します。

MVCに関しては…可読性・保守性の観点から、フレームワークを使わなかったとしてもせめて「デザイン」と「ロジック」の2つの分離はしておきたいところです。私はノンフレームワーク・ノンテンプレートエンジンで小物を作るときも

<?php
ロジック
?>
<!DOCTYPE html>
<html>
<body>
PHPを使うのは変数内容出力目的のみ
</body>
</html>

こういう書き方をしますね。<body></body>の中にechoする目的以外の比較的長い <?php ?> をダラダラ書くようなコードは大嫌いです。

加えて、ちょっと違う視点から回答します。Phalconに対して好印象を持てるのは実行速度だけではなく、「C言語でエクステンションを書けるほどレベルの高い人たちが作っている」という認識があるからではないのでしょうか。

・フレームワークに脆弱性が見つかった場合に対応が必要
・フレームワーク自体にバグが含まれている場合がある

つまり言うところ、こういう不安は「開発元が自分より信頼できない」というところからきているんだと思います。個人的には

「PHPインタプリタのコミッタにはなれなくても、ソースを読んで流れを追えるレベル」

これぐらいの水準のチームであれば喜んで使いたいと思えるところです。あとはちゃんとドキュメントが整備されているかどうか…とかですね。
    • good
    • 2
この回答へのお礼

To_aru_User様

回答ありがとうございます

なるほどですね
やはり「フレームワークを使えば、コミニュケーションを取れない人間も可読・保守が出来る」が最大のメリットとなりそうですね。

しかし、フレームワークを使った場合ってそんな夢のような世界が広がってるのですかね@_@
実際問題 仕様書の一部だけ見て引き継ぎって出来るんでしょうか?
実際問題 grep検索で関数を探すような泥臭いこともないんでしょうか?


>「C言語でエクステンションを書けるほどレベルの高い人たちが作っている」という認識があるからではないのでしょうか。

いえ、特定の言語を使っているから熟練者である有能である、といった考えは持っていません。
C言語使用者の中にも有能な人、無能な人はいると思います。

Phalconを出したのは単純にPHPの上に乗ったものではないからです。


>つまり言うところ、こういう不安は「開発元が自分より信頼できない」というところからきているんだと思います。

そうですね、自分が作ったものであればソースもすべて把握しているので原因が特定しやすいですが
見ず知らずの人が作ったものを全ソース理解せずに間にかませるのはとても不安になります。


じゃあ、サーバのミドルウェアのソース理解してるのか!とお叱りを受けそうですが。。

お礼日時:2014/07/17 11:19

>フレームワークをかませることで


>不具合発生時の原因の特定も複雑になります
>不具合が起きた場合に原因の特定が難しくなる
えっ?それはない。まともに実装しているならログ出力の実装しているだろうし
xdebugでそのログを元にブレークポイントを設定してステップ実行する


>デザイナーもプログラムの知識を持っているチームの場合は
>MVCに作業分担するメリットも感じられません
メンテナンス性。
デザインはこっち。DB問い合わせはこっち。などMVCで実装することによってどこを修正すればいいのかわかりやすい。

>フレームワークに脆弱性が見つかった場合に対応が必要
それ、君が作ったプログラムも同じことがいえるよね。
既存のフレームワークならこっちが気がつく前に改修されてこっちとしてはフレームワークのバージョンだけを上げるだけですむ可能性の方が高い。
それに対してすべてを君が作った場合にはすべて君が改修するんだよ。大変だね。
それと仕事を引き継ぐ場合、フレームワーク部分は読まずに実装した部分だけ読めばいい。
それに対して君がすべて実装したら引き継ぐ人はすべて読む必要があるね。大変ですね。


>・ノンフレームワークに比べて速度は遅くなる(Phalcon等、例外は除く)
速度を気にする実装ならそもそもPHPなんて使わない。Javaで実装する。
    • good
    • 0
この回答へのお礼

ahoo_ok様

回答ありがとうございます


>xdebugでそのログを元にブレークポイントを設定してステップ実行するし
>どうして特定が難しくなる?

必ずログに出力されるような行儀の良い不具合だけしか出ないんであればそれでいいんではないでしょうか
しかし、サービスを運用しているとログに出力されない不具合などザラに出てきます。

そういった場合にフレームワークも犯人として浮上するので特定が難しくなります。



>それと仕事を引き継ぐ場合、フレームワーク部分は読まずに実装した部分だけ読めばいい。
>それに対して君がすべて実装したら引き継ぐ人はすべて読む必要があるね。大変ですね。

なるほど、メンテナンスが容易になるというメリットですね。
そんなものwikiなどでもカヴァーできるし、フレームワークであっても仕様書は必要ですよね
やはりデメリットのほうが勝つ気がする。。。


>速度を気にする実装ならそもそもPHPなんて使わない。Javaで実装する。
これを議論するとパールPHP戦争のようになるので、そうですね。と言っておきます。

お礼日時:2014/07/17 10:15

>やっぱりデメリットのほうが多いですね


フレームワークを使う事に対するメリット・デメリット
だけを見て、フレームワークを使わない事によるデメリ
ットを考慮しないと意味は無いと思いますが?

>作業員の確保も困難になりますし
フレームワークの使用経験が有る作業員であれば、ある
程度のレベルは経験年数や作業内容によって想定が可能
ですが、独自のプログラム形態を採用している場合は、
外部の人間がそれに適応できるかどうかはやってみないと
分からなくなります。
そういった面ではむしろ作業員の確保は難しくなります。

フレームワークを使わない事によるデメリット
・個人毎の技量の差によってプログラムの質が大きく左右
される。
・同じ様な処理が複数の箇所で使われる事で、仕様変更や
不具合修正の際に修正漏れが発生しやすい。
それによる不具合は原因の特定が難しくなる。
・脆弱性が見つかった場合に対応が必要。
使用者の数が少ない為、脆弱性を見つける機会が限られる。
そもそも十分な脆弱性に対する対応が行われているか保証
されていない。
・バグが含まれている場合がある。
    • good
    • 0
この回答へのお礼

don_go様

回答ありがとうございます


>フレームワークの使用経験が有る作業員であれば、ある
>程度のレベルは経験年数や作業内容によって想定が可能

なるほど、そういった側面から見るのも面白いですね。
しかし、残念ながら「フレームワーク使用経験=熟練者」という式は成り立ちません
GETとPOSTの違いも理解していないcake使いもいます。


>フレームワークを使わない事によるデメリット

ありがとうございます。
こういった意見を待っておりました。

お礼日時:2014/07/17 10:34

MVCを理解していない人は容赦なくチームから外します。


理由は#2の回答の方とお同じ。
それくらいフレームワークのメリットは大きい。
    • good
    • 0
この回答へのお礼

kosukejlampnet様

そうですか、かわいそうですね。。

お礼日時:2014/07/15 17:35

特に不自由を感じないのであれば、使う必要はないと思います。

おそらく、自分で管理できる程度の規模のものしか作っていないということではないでしょうか。ある程度小規模であればフレームワークの優位性はあまり感じられないと思います。


例えば、相当に大掛かりな規模のWebサイトを考えてみてください。

数ヶ月をかけて実装し、ようやく本番近くにまでこぎつけました。

そしたら、クライアントの鶴の一声、「データベース変えてくれ」

はい、どうしましょう?

データベースにアクセスするページは数十、数百、ヘタすると数千ページ。どう対処します?

フレームワークであれば、「しょうがねえな」と思いつつ設定変更してDAO見なおしておしまい、です。


あるいは、いきなり仕様変更。データベースの構造が変わりました。

はい、どうしましょう?

全部手書きで作っていたら、データベースアクセスしている部分のSQLをすべて書き直し。数百、数千あります。全部書き終わったら、おそらく数えられないほどのバグが混入してます。

フレームワークであれば、「しょうがねえな」と思いつつモデルの設計を書き直し、DAO書きなおしておしまい、です。


まぁ、他にもいくらでも出てくるでしょうが……。

大掛かりな開発になると、開発の時点であちこち仕様変更があるのが当たり前。そして作ったものはその後何年もメンテナンスすることになります。2年後、3年後、検討の末にSQLサーバーを置き換えました、クラウドに移行になります、といった大規模な変更もあるでしょう。

こうしたとき、すべてあちこちから切り貼りしたコードで組み立てていた場合は、おそらく一から作り直しに近い事態になるかも知れません。が、フレームワークを導入していれば、必要最小限の変更で済みます。
    • good
    • 0
この回答へのお礼

shylock様

お答えありがとうございます
なるほどですね!

データベースに関しては、仕様変更の恐れがあるのであれば
DAOにあたるものをclassで自作すればいいんじゃないかと思いましたが
5人程度のチームであれば自作したクラスも口頭によるコミュニケーションで周知可能ですが
数百人規模であればそれは不可能ですもんね、そういう場合は確かにフレームワーク使ったほうがいいですね

しかしオラクル固有の機能をふんだんに使っているのに、突然ポスグレにしてくれと依頼された時は
例えフレームワークを選択していても簡単には対応出来ないですよね?

余談ですが
Facebook、アメーバピグ、LINEなども数人のチームから始まっていますが
WEBサイト・サービスで数百人規模のプロジェクトってどんなものがあるんでしょうね
↓こういうのとかでしょうか
http://www.touki-kyoutaku-net.moj.go.jp/

未知の領域です

お礼日時:2014/07/15 17:33

メリット


・そのフレームワークを熟知したプログラマが作業すれば開発工数が格段に少なくて済む

デメリット
・フレームワークを熟知していなければ格段に開発工数が増す
    • good
    • 1
この回答へのお礼

t_ohta様

はい、作業員の確保も困難になりますし
やっぱりデメリットのほうが多いですね

お礼日時:2014/07/15 16:12

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!