ん？
Symfonyは最初からPHP5専用なはずだが。
命名の基準がわかりにくい、というかカオスなのは同意だけど。

Symfonyはmojaviのフォークだから、
PHP4時代を引きずってると言える、のかもな。
PHP自体、命名規約がないに等しいカオスだし。

Cakeなんて逆に規約ガチガチ過ぎてぶれようがないだろ
完全オブジェクト指向じゃないってだけで

フレームワークの選定なんて、要件とメンバーのスキルや好みで決めれ
最良なんてのはない、どれが最適かは案件しだい

あと新しく手をつけるのなら資料の多さもおおきいよ
たとえばYiiは、出来はよさそうだけど、日本語ドキュメントが少なくてYiiとかいまいち下火だしな

むしろZendやKohanaの方が自由度が高くて規約で縛らないと偉いことになる気がするけど
SymfonyやCakeは規約から外れると動かないから

>>555
それは仕組みの話であって、規約の話じゃない
こと命名に関しては、Zendは一貫してる

一方、
$this->User
なんてのを一貫した命名規則で扱うのはなかなか難しい、と個人的には思う
＃ これ、MS方式？

>>546です。みなさんありがとうございます。

規約ガチガチのフレームワークというのは、扱いにくいものなのでしょうか。
扱いにくくないのであれば、その規約に従ってみんなが書くようにすればいいだけなので
僕の困っている点を解決するのにピッタリな気がします。

ただ、困っているのは命名規約よりもファイルの読み込み方や変数・配列の使い方です。
読み込んだファイルの中で別のファイルを読み込んで、そこからさらに別の…というふうになっていたり、
セッションや$GLOBALSでデータを回したりしているようです。
仕様書のようなものもありません。
こういうのはフレームワークではどうにもならないでしょうかねぇ…。

>>557
多少は癖が出るもんだし仕方ない
防ぎたければある程度のお手本となるマニュアルを作るべきでは？

>>558
そうですね。この機会にマニュアルを作るのがいいですね。
自分のやり方も癖があるかもしれないので、周りと相談してみます。

フレームワークもやっぱり気になるので、>>2にあるような有名なものを
ちょっと調べてみようと思います。

ありがとうございました。

>>557
それはフレームワークではどうにもならない。
$_SESSIONも$GLOBALSもスーパーグローバル変数で、
そもそもグローバル変数の利用からして制限できないから。

方針としては、バージョン管理を利用したコミットの受け入れチェックなど、
管理面での対応が多分あなたの要件に適したものだと思う。

ソースコードをgrepして、
→ global キーワードは無条件でアウト
→ （ライブラリ以外で）$GLOBALSが存在すれば無条件でアウト
→ （ライブラリ以外で）$_SESSIONの利用も無条件でアウト
→ フレームワークのセッションアクセスメソッド($this->getUser()->setAttribute() など)を
　 重点的に監視

などなど、「これはダメ」って言う基準作りが先。

フレームワークが有用とすれば、>>558の言うとおり「お手本」を定型で示すことができる、
って部分があるかもしれない。

>>560
なるほど。
自分でも何が良くて何が悪いのか頭の中ではっきりまとまってないので
まずは明確な基準作りですね。

バージョン管理も現在は特別なことをしてないので、これから勉強してみます。

とても参考になりました。
ありがとうございました。

それでもクラス変数という抜け道がげふんげふん

抜け道を心得てるような人はちゃんと実装できるでしょｗ

一番重要なのは規則を作ることじゃなくて、個々のスキルと意識の高さだけどなｗ
どんだけちゃんとしたルール作っても、中華コーダーが混ざってるだけでダメになったりする

あと、拘りがある人、というか堅物や変人とかがいると、
俺はこういう書き方をするんだ！って主張したがるから、そのあたりも非常にうざいことになるｗ

は？

>>564
個々のスキルと意識の高さが重要なのは同意だけど
コーディング規約を守らせられない現場はどうなってるんだ？

派遣の寄せ集め所帯なら仕方あるまい

ベンダコントロール能力ゼロの無能PLってことだろ

新選組みたいなもんだ
土方歳三レベルのPLでないと纏まらん

いや大多数のプロジェクトでは普通に規約守られてるだろｗ

派遣の寄せ集めでも規約は守らせるだろ
最初の1週間はしょうがないかもしれないけどさ。

ここはフレームワークスレなわけだけど
フレームワーク使ってるならなおさら規約は守るものだと思うけどな

最初に規約の説明とフェーズごとにコードレビューやるかどうかだけであって
外国人がいようが慣れてない派遣がいようが関係ない話だろ
別に規約はそんな重視しないで自由でいいよって方針のプロジェクトも多いけど
守るのが前提ってプロジェクトで守れないのは単にリーダーがバカなだけ

でも実際そういう案件も腐るほどある現実
規約があってもコードレビューとかやる余裕のないとこだと、
結局形だけのルールになってたりするのも見るしな
なんにせよ、フレームワークとはあんまり関係ないけれど

ただ糞みたいなコード書いてるような案件は、俺俺フレームワークを作ってるか、
既製品つかってても、使う意味がないような使い方しかしてないことが多いわなｗ

規約守れないなら少なくともCakeは絶対無理だと思う

>>573
そんな低劣なとこと仕事してるのか。
お前みたいな底辺は大変だな

建築現場だとぶったたいて教育できるけど
ITの現場はぶったたくと死んじゃうからなぁ

PMおつかれさまです！

ITの現場ならコーディネータ呼んで
あいつなんとかなんないならお宅の会社更新なしね
で一発だけども

せちがらい

>>576
これ、modelは自分でいちいち書かないと駄目なのか？

modelってのはたぶんテーブル定義のことなんだろうけど、
コードに定義が書いてあるのは結構好きだな。
コードだけ見ればデータベースの設計がわかるから。
RailsとかDjangoみたいにコマンド一発でデータベースに
テーブルが追加されたりするのかな

公式ページ上部のメニューバーがFlashなのが微妙

>>583
どういう畑で作業してるのか知らんが、
ある程度の規模だと、構造設計・実装とDB設計は別になるだろ。
てか、DBの構造をコードから判断とか、バグ(仕様把握ミス)の
温床以外のなんでもないんだけど。

ドキュメントが整備されるならドキュメント。
整備されないなら、admin系ツールでちゃんと確認して組めよ。
ま、お遊びプロジェクトで遊ぶんならいいんじゃね?てとこ。

何を言ってるんだお前は

>>584
それは言い過ぎ。
モデルをきれいに書けば、誤解しようのないコーディングが出来る。
ドキュメントもきちんと書かなければ、バグの温床になるだろう。

きっちり書かれてない紙切れはドキュメントとは言わないだべ
エクセルだろうけど

Excelで書いたから駄目という理由が分からんけども。

Excel仕様書でまともにドキュメントを管理できてる案件にまだであったことがない
かといってWordだと馬鹿連中が書きながらどんどんぶっこわしていって、手のつけられないような酷いことになる方が多い
どちらがいいとはいいきれない。一長一短

スレチうぜー。ｱｯﾁﾃﾞﾔﾚｰ

>>589
お前が配属されるプロジェクトがことごとくレベル低すぎなのは解ったから
自分の能力の低さを自慢しないでくれ

フレームワークを学んだ得たこと
CakePHP,Zend

1.売れるシステムにフレームワークは関係ない
2小規模なシステムは一人で構築した方が早い。フレームワークでチームでやるメリットがない
3.毎度毎度、違うシステムを作るわけではない。なんでも作ります屋さんは案件とれない
4.フレームワークを習得するのに時間がかかる。その間に売れ筋のシステムを構築できた。機会損失もあわせて、でかい

結果、１～２人で制作する分にはフレームワークはいらないし
フレームワークのおかけでもう儲かった利益はなく、習得してから２年経過するけどマイナスでしかなかった
フレームワーク　＝　重いというイメージさえついてるから売りづらい

>>592 そんな化石世代のフレームワーク持ち出されてもなぁ。

OpenPNEなんてSymfony採用してからプログラマの参入障壁が高くなって
プロジェクトの進行やアイディア不足に衰えを感じる。
しっかりとした枠組みが必ずしも流行するわけではない。
phpがWEB言語として活躍できてるのは、とっつきやすさにあると思う
それをあえてフレームワークで難しくするのはPHPのメリットを殺してると思う
プロジェクトに参加できる全ての人が天才ではない
集団の英知を実現させるのなら、規律が最小限のフレームワークである

>>592
今はDooPHPの時代です

フレームワークでどれだけの利益が出たか？
俺はほとんど利益に貢献できてないと思う。
新しいフレームワークが出れば、それを覚えるのに時間がかかる
これを繰り返すくらいなら、フレームワークなしで売れ筋のシステムをたんたんと作ってた方がよい

新しいフレームワークが出れば、今までの蓄積リソースは無駄になる
これって毎度毎度、無駄にしていかないといけない
これでは利益率は上がらない

保守性低い

新しいフレームワークを使わなきゃいいだろうが

フレームワークを使うなら新しいのじゃないとメリットがない
改善されて使いやすくなってるから