元スレ【PHP】PHPフレームワーク総合スレ14

php覧 / PC版 /

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

551 = :

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

553 = :

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

554 = :

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

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

556 = :

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

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

559 = :

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

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

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

561 = :

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

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

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

562 = :

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

563 = :

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

564 = :

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

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

566 = :

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

567 = :

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

568 = :

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

569 = :

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

570 = :

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

571 = :

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

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

572 = :

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

573 = :

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

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

574 = :

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

575 = :

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

577 = :

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

PMおつかれさまです！

578 = :

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

579 = :

せちがらい

582 = :

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

584 = :

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

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

585 = :

何を言ってるんだお前は

586 = :

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

587 = :

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

589 = :

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

590 = :

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

591 = :

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

592 = :

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

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

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

593 = :

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

594 = :

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

596 = :

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

597 = :

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

599 = :

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

600 = :

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