結局PHPのフレームワークってどれがいいの?
■ このスレッドは過去ログ倉庫に格納されています
最近Cakephpの勉強始めたんだが
コードがダサくて嫌なんだけど
ていうかarrayうざい
そもそもcakephpって名前がダサくて嫌だ
どれ次に勉強すればいいかな?
laravel symfony2 zendFramework CodeIgniter Yii >>791
MVC自体はほぼcakeとおんなじ
キャメルケースとかネームスペース拡張してつかう感じ
でもララベルおっそいんだよなぁ >>792
Cakeもそうだが、LarabelとかのSymfony系は、自分で書いたコードが実行されるまでのステップが膨大だから、そんなのに全体のパフォーマンスを求めちゃいけないわけ。
パフォーマンスを落としても得られるメリットの方が大きければ採用する意味はあるが、少人数で開発できるものにそういう長大重厚フレームワークを採用すると、足を引っ張られたと感じるだけだろう。
CIはそういうことをやってないから高速なのは当然で、逆にCIに長大重厚フレームワークらしいことを求めちゃいけない。
個人的な感想だが、CIほど自由なら、いっそのことオレオレフレームワークの方が効率良く開発できると思うし、実際そうしている。 >>793
君がいなくなったあと、そのオレオレをメンテする身にもなってくだされ。
「オレオレの方がいイイ!」という人って後のことまったく考えてないよね。 >>796
ポピュラーなフレームワークは経験者が多いからPGを探し易い、というのは重厚長大フレームワークを選択する理由として良く聞く理由付けだが、Myフレームワークはシンプルだからphpを“まともに”読み書きできる奴なら誰でもメンテできる。
そのメンテですら四苦八苦する奴はPGとして使い物にならないと言える。
また、そんな低レベルPGでも、SymfonyやCakeだと突然気の利いたコードを書けるとでも思っているのか?お笑いだ。
そんな素人紛いのPGがまともな成果物を残せると期待しているのは、>>796のような商業PGとしてコードを書いた経験のないSEとPMだろう。
類は友を呼ぶのはこの世の習わしなんだなとつくづく思うわ。 >>798
誰でもメンテできるか検証したの?そのオレオレフレームワーク。
例えばバグとかちゃんと潰してある?
セキュリティリスクはない?
妄想で語られてもね。 >>798 は人の書いたコードをメンテしたことないのかな。
先ず沢山の人のレビューを経たコードと
自分しか見てないコード。どっちを信頼する?
全部自分の目で確認するから問題ないって言うなよ。
そういう奴は、工数を考慮したことがない素人だから。 >>799
心配ご無用。
>>799がそれを目にする日は一生来ないだろうしなw
つかその前に、ポピュラーなフレームワークはバグとかちゃんと潰れててセキュリティリスクはない、とか思ってるわけじゃないよな? >>800
君らはオープンソースの怖さを知らないだけだよ。
SymfonyやCakeが高速で動作し且つ開発期間を短縮でき且つ学習コストが低いなら一目置かざるを得ないがな。実際は真逆だろ。 >>801
もちろんゼロだとは思ってない。
でもコードの信頼性の指標にはなる。
ユーザーが多いからバグを見つけるし修正される。
そのオレオレフレームワークはどのくらいの人が使ってるの?
結局初歩的なバグが潰されてる可能性があるだろ。まさか自分の書いたコードにバグはないとおもってないよな? >>800
他者が書いたコードのメンテなんか日常茶飯事。
低レベルPGが書いたコードも嫌というほど見た。
実際、そういう奴らが明けたセキュリティホールを塞ぐ仕事もしてるし、オープンソースの結構大きなバグも見つけてる。
脳内プログラマには理解できなくても無理はない。 オープンソースの怖さってなんだよ。
お前が使ってるphpとlinuxもオープンソースなんだが。 >>804
なんでオープンソースに貢献しているやつが
わざわざオレオレフレームワークつくるの。さっきから支離滅裂なんだけど。 > 個人的な感想だが、CIほど自由なら、いっそのことオレオレフレームワークの方が効率良く開発できると思うし、実際そうしている。
負債産み出してる戦犯が何か言ってる なんだ。そういうやついるのかと思ったけどそういう釣りなのか。
オレオレフレームワークがベストって言ってる開発者がいるのかと思った。
オレオレフレームワークで仕事してるやつと仕事したことあるけど
学習コストは結局既存のフレームワーク並みにあったくせに
結構簡単にバグが見つかるし、実行時エラーがでても原因が特定しづらいしキツかった。
結局他のユーザーに鍛えられてないからエラー処理系が貧弱なんだよね
作ってる本人は俺的最強だから本人にとっては分かりやすいんだろうけど。 まぁそうムキになるなよ。
人生の中で得られる教訓は人それぞれ違うんだし、そもそもフレームワーク教の信者に改宗を迫ってるわけじゃない。
君らはこれまで同様重厚長大フレームワークを重用し続けてれば良い。
オレは単に、学習コストが高い+動作が鈍い+工数短縮に寄与するわけじゃない、つう重厚長大フレームワークの欠点を指摘し、そんなもん好んで使わないよって言ってるだけだ。
実際、業務でそういうものと付き合わざるを得なくなった時には、嫌々ながらもやってる。
だからこそ、その短所が目に付き、それを十分に補うだけの長所が見つからない、つうことだ。 >>806
自称世界最高峰エンジニア様なんだよ
だったら、PHPに変わる言語を開発して欲しいところだがw ボトルネックになりそうな部分は全部拡張モジュールにしろよ ボトルのネックって皆が気にしてくれて良いなぁ
俺の肩コリなんて解消されないのに
あ、でもボトルの頭は直ぐに飛ばされるから
その辺は首チョンパされないぶんお気楽なのか、、、 >>811
残念ながら、そういう悲しい現実はフレームワークとは直接関係ない。
クソコードは低賃金PGの得意芸なのであり、有名フレームワークを使ったからと言って排除できるものではない。
フレームワークを使えばソースコード全体におけるクソコードの比率は下がるだろうがそれは見掛けの数字であり、フレームワークにさえクソコードを混入させていたら状況はより混沌とする。
そういう悲しい現実を減らすには、コードを書けない奴をSEやPMとして置かないこと、低賃金PGの作業領域をできるだけ減らし且つ低賃金PGの作業は上級者が必ずチェックして指導することしかない。
そういうことを知らない奴らが営業したり経営している限り状況は改善しないだろう。 そう、ホットスポットは出来るだけ局所化、極少化すべきであり、そのホットスポットさえもジェネレータなどで極力自動化すべきなんだよね laravel って「職人のためのフレームワーク」 なんだよな・・・
そこが最大の欠点だと思う お前らのくだらないプライドのために会社の利益を下げてることに気付け
シェアが高いものはとりあえず否定
↓
マイナーなフレームワークを使う
↓
他の社員がメンテできない
↓
派遣や契約に丸投げ
↓
無駄なコストがかかり、社内の技術も上がらない >>820
詳細を求む。具体的な欠点とかあげてほしいわ Laravelはsymfonyみたいにバンドルスタイルにしろよ
再利用性悪すぎてかなわんわ >>819
Laravelのドキュメントに書いてあるだろ >>822
> シェアが高いものはとりあえず否定
全然違うね。まず、シェアの高低なんか全く関係ない。利用数が少ないという理由だけでフレームワークを選択するのは不合理だ。
> マイナーなフレームワークを使う
そもそもフレームワークのシェアに関する正確な数字はないはずで、マイナーかメジャーかという切り口自体が幻想である。
ブログなどでフレームワークの人気度を測るバロメーターとなっているのは、Googleでの検索回数の多寡ではないか。
検索機会の多さは分かりにくさを示唆している可能性があり、使い方に悩んだ上での検索が多いのであれば、使わない方が無難かも知れないのだ。
> 他の社員がメンテできない
社員のプログラマとしての能力が低ければ、何を持って来ても同じ。
プログラマとしての能力が高く、且つ学習コストの低いフレームワークであれば、初物でもメンテは困難ではないだろう。
> 派遣や契約に丸投げ
> 無駄なコストがかかり、社内の技術も上がらない
仮にその会社ではSymfony系しか扱わず、そこの社員はSymfony系なら対応できるということであったとしても、それはその会社でしか通用しない。
現実社会は多様であり、転職したら未経験のフレームワークと向かい合うことになるのは火を見るより明らかだ。
そこで躓くようなら、それはつまり、前職で習得した技術が役に立たないことを意味する。
マイナーなフレームワークに触れていると社内の技術が上がらない、というのも幻想だ。
派遣や契約への依存=無駄なコストという考えも誤り。一時的に彼らへの依存を高めたとしても、そこから得らるものを得ようとしないから“無駄なコスト”に思えてしまう。
余程頑固な会社でない限り、未経験のフレームワークが要求される案件を請けることはいつでもあり得る。
だからこそ、学習コストの高いフレームワークは邪道だと思う。
そういうものを嗜好する人は宗教に似た思い込みに取り付かれているのではないか。
いわゆる洗脳である。 シェアの高さは 情報の多さに繋がり 学習コストを引き下げてくれるからな
「みんな使ってるから これにするわ」 ってのは 結構正しい選択なんよ つまり日本じゃCakePHPってことになるのけ?
たしかに日本語ドキュメントは圧倒的に多いみたいだけど >>829
肝心なシェアはどうやって知るの?
その数字は正確なの?
シェアの変化に追随するの?
そもそも>>829は自分でコード書いてるの? >>829
そうだね。
ググればいくらでも答えが出てくるならそれに越したことはない。
俺は小さな会社経営してるんだけど、たまに依頼あるのよ。
協力会社に作らせたサイトに手を入れられなくて困ってると。
そういうのは決まってオレオレか日本ではマイナーなフレームワーク。
ソースコード見ると、たしかに技術がある人が書いてそう。
でも、いかにも「このくらい分かるだろ」と言いたげな傲慢さも感じられる。
ソースコードでそれを読む人をねじ伏せようとしてるかのよう。
そうなっちゃダメだよね。
まあ、その手の困ったちゃんがいるから俺らも食いっぱぐれないんだが。 ってことでやっぱりLaravelか
海外の評価は正しいんだな
俺は自作フレームワークだけど phpはソース読めばわかるだろの姿勢がデフォだと思ってたわ。
いちいちドキュメントなんて書いてらんないし >>838
書いてらんない?w
本音はどう書けばいいかわからないんだろ? で、>>842は自分でドキュメントやソース書いてるのか? PHPとJavaほど、下手くそが書いたコードが読めない言語もそうそう無いような… フレームワーク初心者はどれ使えばいいんだ
書籍をあたるとCakeとLaravelくらいしかないみたいだけど
英語読めないんで日本語ドキュメントがないと使い方わからん laravelでいいんじゃね
日本語の入門書なら腐るほどあるよ
qiitaにもlaravelタグの投稿は1571もあるし、別に困らんと思うけどな 縁は大事だ、今から始めるならつい数十時間前にリリースされたばかりのLaravel 5.5 LTS使いなよ やっぱりLaravelかぁ、ちょっと書籍あたってみる、ども PhpStormと相性良いフレームワークってなに? >>857
フレームワークをIDEに合わせるなんて愚の骨頂
「yiiが一番合う」と言われたらyii使うの? >>860
聞いたってええやん
このスレ覗いてる人にはそこそこ需要あると思うで これだけ乱立してるってことはどれもクソなんだろうな、
と思い避けていたフレームワークなのだけど、
とうとうSymfony使ってYoというリクエストがきてしまった。
これって要はコピペして使えってことなの? >>863
なぜAPIだけ別建てしようとしているのか分からんが、
別建てが不可避であれば、
APIは高速性が重要だからフレームワーク非依存で作った方が良い。
既存フレームワークの採用が不可避であればCIかPhalconあたりになるだろうが、
そんなことをする意味があるのか? >>864
また被害者が増えたか。
Symfonyがコピペで済むようなものならもっと流行ってるだろ?
Symfony派生のフレームワークがいくつか出てきていることは、
Symfonyには結構な問題があることを示唆している。
Symfonyが総合的に素晴らしいなら派生が注目されることはないだろう。 >>862
だからさあ、愚の骨頂だって言ってんだろ!
俺が豊田議員だったらお前の頭髪の少なさを罵倒しまくってるわ
てか、他の奴もそうだが「何がいいの?」とか他人に聞く前に自分で試せよ
phpstorm入れてその辺に落ちてるソースコピペしてみりゃわかんだろ
なぜその程度のことをやらないだ? バカかよ
Phpstormと相性が良くてかつそれなりに使えるFW探すのは別に愚の骨頂じゃねーだろ HEYSiri 結局PHPのフレームワークってどれがいいの? そのうちPHP自体に公式フレームワークが内包されるであろう PHPってWebに特化した〜みたいな謳い文句だった気がしたけど
他にどんなシーンで活躍してるんだ? >>876
訓練されたPHPerはCLIアプリもPHPで書いてる。 CLIアプリを書くのにPHPで一番困るのは、スレッドのサポートが貧弱なことだと思うんだけど、なんかいい方法あるのかな。 そのプロジェクトがphpならphpでバッチも書くなあ
「おれっちphpしかわからねえ!!!」ってのが携わることもあるだろうし
メインがphpならphpでpythonならpythonでc#ならc#で
railsはバッチとか書いたこと無いからアレだけどrubyになんのかね 366 :nobodyさん 2017/05/29(月) 16:07:39.16 ID:6v4UcGhE
今回の民法改正、ソフトウェア受託開発の場合、(検収後ではなく)バグ発見後1年瑕疵担保責任があるということで、地獄かよ、と思ったが、
元々問題が起きがちな受託案件がビジネス的に成立しなくなることで強制的に業界再編につながるなら良いことかもと思うようになった。
一部で地獄を見ても。
https://twitter.com/yukihiro_matz/status/869061879389343744
367 :nobodyさん 2017/05/29(月) 16:28:06.55 ID:6v4UcGhE
ニュース - 改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大:ITpro
http://b.hatena.ne.jp/entry/itpro.nikkeibp.co.jp/atcl/news/17/052601508/
372 :nobodyさん2017/05/29(月) 19:10:37.12 ID:???
Railsでシステム作って納品する
↓
Railsはマイナー、メジャーのアップデートが半年以内に必ずある
↓
客がアップデートする。アップデートによるエラーやバグ、動作の不具合に気づく
↓
気づいてから1年以内に通知すれば、5年間無料保証ゲット
↓
つまりRailsがアップデートするたびに、無償の修正作業を発生するということかな
376 :nobodyさん2017/05/30(火) 09:20:20.09 ID:L5po86sS
>>378>>379>>375
客が瑕疵担保責任法の法改正を知ってくると思うから、今後5年無償保証をお願いされるだろう
営業がそれでも仕事を取ってこれるか?たぶん無理だろう。無限の直していたら赤字になる。
こういう保守に弱い言語、ころころ仕様が変わる言語は仕事として発生しなくなってくる。
これは変わり目だ。お前らも早く逃げたほうがいいぞ。RubyやPHPなど動的言語は確実に廃れる。
保守に強い言語のみ生き残れる。 >>881
複雑なモデルアクセスとかも使いまわさずいちいちgoでまた書くの?
スレッドが欲しいのってCLIよりWebアクセスの時とかの方が多いと思うんだが
PHPのCLIでやることなんてちんたらしててもそんな問題ないし てか、複雑な処理をするなら最初からphpは選ばんわな
phpだけだと出来ないこともあるしな ■ このスレッドは過去ログ倉庫に格納されています