>>496
というかFW無しで、それなりの規模でしっかりしたWEBアプリ作れるように新人教育する方が確実に大変だろ・・

>>492
きちんと使ってもいないのに語るのはやめた方がいいよ。
MVCきっちり分かれてるし、自由に切り替え可能。
モデル使わないコントローラーだって当然可能だし。

>>501
FW使っても設計が出来ないと、大規模開発には耐えられないけどね。
PHP自体をしっかり憶えて、そういう基礎知識を伸ばす方が重要だと思う。

>>500
規約がかっちりしてるからパラレルに作業しやすいとかかな

>>503
規約ってどのくらいの範囲まで及んでるのかな？
ディレクトリ名とかファイル名とかクラス名とかDBのテーブル名とか参照できる変数名とかキーの名前くらい？

>>504
名前じゃなくて中身が本質なんだと思うがｗ

命名規則とかタブ幅とかが書かれたコーディング規約だけじゃなくて、
CoC的な意味での設定とか規約とかも含めた、構造そのものが範囲じゃないかな。

すげーざっくり言うと「コードを書く場所を機能別に分ける」ってことだよ。
ファイルを階層別に分けるのも、命名規則をつけるのも、その目的を果たすためにしたことだ。

個人的には、symfonyが大規模案件に向いているというのはすごく眉唾で、
「PHPの実績あるフレームワークで大規模案件をやるならsymfonyしか選択肢がない」
というのが日本の実情に近いんだと思う。

それだけ聞くと別にsymfonyじゃなくても良いと思えてしまう。

勿論、設計がしっかりしてりゃなんだっていいし、別にオレオレフレームワーク作ったって構わないわな
「設計がしっかりしてる」ってのをどこで判断するんだ、って話だ
symfonyに限らず、実際にそのフレームワークで構築された大規模サイトがある、ってのは、大規模な案件になっても設計的に破綻しないという何よりの証明
採用件数が多ければ、トラブルシュートの類も蓄積されてるだろうしな
ユーザー数が多いという事は、本体の開発者も多い事が期待できるし

日本においてはその限りでは無い気が･･･

うーんぶっちゃけ、そんなに「開発規模が大きくなる事」とか、
「開発規模が大きくなることを念頭に置かれた設計である事」に魅力を感じるか？
と自分に問うと、自分の場合はそうは思わん。（仕事の面白さ的にも）

ただ「運用していくうえでのスケーラビリティだけは確保しときたいよね」って所と、
コードの見通しの確保、あと万一ソースコードを他者に引き継ぐとかって話になった時に
話が少しだけ早くなる、っていう3点だな。
自分がPHP案件でオープンなアプリケーションフレームワークを利用する意味は、そのくらいだと思う。

まあ、自分みたいなタイプは少ないかもしれん。
もしかしたら結構みんな、多数の人員で多くの人月かける仕事が好きなのかもしれないし。

>>509
俺は大規模案件に魅力を感じる。
みんな知ってるあのサイト、実は俺俺フレームワークで動いてるんだぜ、
とか言ってみたいものだわ。そういうのに挑戦していきたい。

「Railsもどきを作りましょう」じゃなくて「案件ありき」で作った。
俺がsymfonyをリスペクトしてる理由は、それだけだな。
フレームワークとしてはちっとも高性能でも万能でも無いと思うが、
大規模案件のお手本にするには十分ためになるよ。

あと、微妙に「大規模」の定義がずれてるような気もするｗ

アクセス規模が大きい、って意味の大規模だと、symfonyやcakeは微妙だな
最終的には素のPHPで必要最小限の処理を手続き的に書くのが最速になる

この場合の「大規模」は、機能数や、エンジニア数（工数）という意味での「大規模」だと思う

規模がでかいんだったら俺ならJavaにするな

規模がでかいんだったら俺ならYiiにするな

yii使ってる人いるの？

個人的に使い始めてる人はいると思うよ
いろいろ便利

Javaって共有レンタルサーバーで使えるようになるかな？

もちろん探せば使えるところあるだろうけど、
PHPぐらいにたいてい対応しているレベルになるかなってこと。

スレ違い

>>517
うるさい

スレ違い

共有鯖で大規模サイトやりたいのか？ｗｗｗ

スレ違いと言ったらうるさいと言われた。ワロタ

>>510
>>511
確かに「工数としての大規模」と「アクセスが大規模」の話がこんがらがってるね。
自分が言いたかったのは、前者の意味での大規模に、それほどの面白みを（個人的には）感じないという事。
でも、当然アクセス規模が（意図する・しないにかかわらず）大きくなるような案件には夢を感じる。
そういう時に、後からスケールアウトしやすく設計されているフレームワークを使っておくのはひとつの手だと思う。
最初からDBレプリケーションだのmemcacheだの利用した実装してアクセス全然だったらアチャーって思っちまうし。

話のポイント外してるようだったらごめん

個人的にはZendみたいなライブラリ集っぽいモノに、
俺俺フレームワークをかぶせるのがベストプラクティスだと思っている。

DBとかセッションとか普遍的なロジックはライブラリ集を使って、
認証やバリデーション、コントローラ/モデルあたりの毎回ロジックに改修が入る部分は、
自分の使いやすい方式で実装するのが良いと思う。


質問スレとかで、自分で書けば数行のものを、むりくりフレームワークを改修して実現しようとしている人を見ると微妙な気持ちになるわ。

>>523
はげしく同意。
フレームワークを使っても、毎回どっか改造しなきゃいけないところがあって、
なんかフレームワークを使ううまみがかなり減るよなーといつも思う。

自分ひとりでやるならオレオレでもいいだろう。
けど他人が絡むのであれば、それではまずいだろう。

>>525
個々がフリーダムにコーディングしてしまうとまずいだろうが、
ある程度の規定を決めて社内フレームワーク的なモノにすればよくね？

仮に特定のフレームワークを導入したとしても、連携とれるかどうかは別だしさ。
むしろ既存フレームワークを誰かがカスタマイズしてしまうと、余計にカオスな状況になる気がする。

設定ファイルで全て賄おうとする思想のフレームワークが嫌いだ。
大抵、設定ファイルという名の新言語になっている。

>>526
>むしろ既存フレームワークを誰かがカスタマイズしてしまうと、余計にカオスな状況になる気がする。

ほんとだよ

> 個々がフリーダムにコーディングしてしまうとまずいだろうが、
> ある程度の規定を決めて社内フレームワーク的なモノにすればよくね？

であれば既存のフレームワークでいいのでは？
なぜ、車輪を再発明してまでFWを自作したい？

よっぽど特殊なドメインのWebシステムで無い限りはそんな必要性ないかと。

ようするにエンジニアだから。
全部自分で作ってみたいんだよ。
フレームワークみたいなブラックボックスが我慢できないんだよ。

Cよりアセンブラと思ってた時期もあったな

FWのソースを見て理解出来ないようなヤツは、
ハナから黙ってそれを使え。

>>526
結果的に使う人にとっては、同じようなFWになる気がするけど
自社だろうが、既存フレーワークだろうが使用するだけの人にとっては今まで出てきたような問題のメリットもある。

すでに十分な機能の自社フレームワークがあるならいいけど、既存のFWより機能の少ないものを作ってそんなにメリットあるのかな。
速度?でも色々付けたらそんな変わらないんじゃないの?

>>533
「問題のメリットも」じゃなくて、「問題もメリットも」
でありますw

>>529
>であれば既存のフレームワークでいいのでは？
おまえさ、もうちょっと話の流れを追ってから書き込もうぜ。
526だけじゃなくて、もうちょっと上の523あたりから読んでみなよ。
既存のフレームワークに問題点を感じているから話がはじまったのに、
「既存のフレームワークでいいのでは？」とはこれいかに。

> フレームワークを使っても、毎回どっか改造しなきゃいけないところがあって、

っていうか俺今までいろんなフレームワーク使ってきたことがあるが、
フレームワーク自体に手を入れなきゃいけなかったことなんて一度もないんだが。
単に、フレームワークを使いこなせていないだけなのでは？

FWの設計的に想定外の処理を追加したい場合とかに
大げさなラッパーコードを書かなきゃいけないのが不毛だって話だよね。

てゆーかどんなフレームワーク使ってても、
自然とそれを覆う為の俺俺フレームワーク(クラス群)が出来上がらないか？

>>536
フレームワーク自体は書き換えないだろ･･･
それを覆うコード群が膨大になると結局カオスになる。って事かと。

>>529
>>533
全てを再発明するわけでは無いよ。
既存フレームワークの設計上、実装が面倒になりそうな部分は、自前で書く方がメリットあるんじゃない？

既存フレームワーク ＋ 自作の使いやすいコンポーネント ＝ 俺俺フレームワーク

きちんとしたFWでそこまで大きな改修やラッパーが必要になるかな・・
っていうのは同意

特殊なものを作ってるのかもしれないが

ZendFramework使ってるけど、コアな処理にZend系クラスを直で使ってしまうと後々カスタマイズが出来ないので、
継承クラスや、ラッパーを作って使っている。

普通はするよ・・・ね？

そもそもZFは使ってないけど、他FWのライブラリとして使ってるという印象。

こういう種類があるということか。

1. FWなし
2. 100%俺俺FW
3. 100%一般的なFW
4. 一般的なFWの上に、俺俺FW

俺の場合、新しいプロジェクトを作るときは、たいていそれまでに作った
似たようなプロジェクトのコードをテンプレート代わりに使ったりするから、
上の分類だと4ということになるのか？

>>542
正直1と2はスレ違いな気もするw

>>540
この意見よく聞くしよく見るけど、実際にラッパーにしといてよかったーって
場面はあまり見たことない。

実際に使うのは下っ端ですから・・・

>>544
自分の場合はZFの不具合(日本語系)に悩まされて、パッチとしてラッパー作るようになったｗ

>>546みたいに問題が起きたり問題が起きそうなクラスだけ
ラップするのは普通だし現実的だと思う

>>540が何でもかんでもとにかくラップするっていう話なら
ちょっと無駄な気はする。まあ、何でもかんでもってことは
さすがにないか

既存のシステムからのコールを、極力回収や学習をしなくてもいい形にZFにつなぐためのラッパーならも
ありかなと個人的に思う。
学習についてはいろいろあるだろうけど、今まで作ってて結局周りを巻き込んで学習する時間なかったり
するもんで、php4とかで使用してたライブラリのコール仕様になるべく併せた形に書き換えて作ったことは何度かあった。

>>522
> 後からスケールアウトしやすく設計されているフレームワーク

実際、無いよなあｗ

だから、俺俺フレームワークでラップしてるような気がする。
開発者や開発案件の思想に依存する「俺俺スケール」が先にあるのかも知れない。

やってる事がbug-fixにとどまらず、俺俺部分に意志が入っちゃうんだよね。
>>542の分類で言うなら、
「一般的なFWの上に、俺俺bug-fixを加えただけのもの」
があってもいいはずなのに、なかなかそれだけで改造が終わることが無いｗ

インスタンス生成部だけ独自実装して素のZend使えばいいんじゃね。
差し迫った必要に迫られても、同じインターフェイスを持つ別のクラスを返すようにすればサクっと入れ替えられるしな。
まあ、DIなわけだが。

俺の場合、PDOのラッパークラスはかなり頻繁に作るな。フレームワークじゃなくて言語組み込みだからちとアレだが。
全メソッド呼び出しを記録できると色々便利。