ああああフレームワークの利便性を理解するためにはチーム開発に参加する必要がありますか

Question

お恥ずかしい話しなのですが、今までマトモにチーム開発に従事した経験がありません。それ故なのかもしれませんが、フレームワークの利便性がイマイチ理解できません。

フレームワークの利便性を理解するために、個人的に一人でフレームワークを使って開発を試してみました。使用したフレームワークはDjango(python),fuelphp(php),larave(php),express(node.js)などです。フレームワークに関して調べると、どれも結局MVCがどうのこうのという説明の元「開発スピードが向上する」「バグが減る」「書き方が統一される」など色々メリットが書いてあります。

そして実際に、上記のフレームワーク達はそのような仕組みが内部に存在していました。しかし、モデルとビューと、コントローラーを分けけたところで、そんなに便利でしょうか。確かに、便利は便利なのかもしれませんが、フレームワークの利便性の根幹はそれのみなのでしょうか。

開発環境を揃える方法や、dbを操作する方法を初めから知っていた場合、最初からそっちを使った方が早いとすら思ってしまいます。こんな風に考えてしまうのは、おそらくチーム開発の経験が極端に少なく、様々な人がフレームワークありで進めてきたプロジェクトに後から参加したりしたことがないのが原因でしょうか。

確かに、以前、フレームワークなしで長年推し進められてきたウェブサービスを一人で抱え込んだとき、その中身に散らかりっぷりに戸惑った経験があります。フレームワークを知っていると、このようなことがなくなり、メンテが楽になるのでしょうか。そうであれば、フレームワークは比較的中規模なプロジェクト、もしくは自分以外のエンジニアが引き続き改修していく予定が初めからあるプロジェクトになって初めて威力を発揮するもので、フレームワークの利便性を感じることができるのは、チームプロジェクトの中のみということになりますか。

テスト環境と本番環境をコード書き換えで簡単に行ったり、フレームワーク内でできるのは、使いこなせれば、便利なのかもしれません。。

https://qiita.com/qwe001/items/96a83fadcfaeb3cd4a6e

経験談で構いませんので、色々お話しをお聞かせいただければ幸いです。

Comments

[Orlofsky]

URLは 対応しているMarkdownの機能 https://teratail.com/help#about-markdown の[リンク]を使いましょう。

[m.ts10806]

タイトルがおかしくなっています。ノイズにしかなりませんので調整してください。

[motuo]

知りたいのは、「チーム開発に参加する必要がありますか？」でしょうか。または、「フレームワークの利便性」なのでしょうか？

[m.ts10806]

今更ですが、laraveではなくLaravelですね

Answer 1

開発環境を揃える方法や、dbを操作する方法を初めから知っていた場合、最初からそっちを使った方が早いとすら思ってしまいます

おそらくフレームワークの学習コストのことを仰っているのだと推察しますが、
そこは開発期間や納期との兼ね合いもあるかと思います。
ただ、「dbを操作する方法を初めから知っていた」としても、実際はその「dbを操作する仕組み」を作っていかなければなりませんよね。
開発は1人で行うことはほとんどありません。その仕組みを作ったとしても結局のところ他のメンバーがその部分を理解して使わなければなりません。

いわゆる「オレオレフレームワーク」は往々にしてマニュアルが残りません。
例えマニュアルがあったとしてもメンバーが好き勝手に機能追加していく内にマニュアルがメンテナンスされなくなっていきます。
最初に基盤を作った人がいつまでもいればいいですが、いつかはいなくなります。
そうなったときに「最初に作った人すら全て把握しきれていない」現象も起きて、引継ぎも満足にできないまま次のメンバーに引き渡されます。
そうなるとマニュアルも残っていない（最新ではない）ため、結局ソースコードを見て理解するしかなくなりますよね。
その時間は非常に無駄です。例え熟練者であっても他人のコードを完全に理解して、作った人と同様以上に使いこなすのは難しいです。

で、あれば、定期的に正しくバージョンアップが行われ、必要な機能は最初からきちんと揃っている
マニュアルも常に最新化されている著名なフレームワークを利用する方が比べ物にならないくらい後々のメンテナンス性含めて高いパフォーマンスを発揮できることは間違いありません。

もちろん「オレオレフレームワーク」であっても、きちんと役割分担がされていてメンテナンスがされていてマニュアルも過不足無く更新されていれば問題は少ないかと思いますが。
それとこれとはまた別問題なので割愛させていただきます。

モデルとビューと、コントローラーを分けけたところで、そんなに便利でしょうか

先に「開発は1人で行うことはほとんどありません」と書きました。
スポーツに例えると分かりやすいかもしれません。
団体スポーツには殆ど「ポジション」というのが存在します。
野球ではピッチャー・キャッチャー・・・サッカーではキーパー・フォワード・・・
バスケットでは・・・●●では・・・。
サッカーやバスケットでは昔はなかった概念が入ってきたりで内部的には更に細かくなっていることもありますね。
それは「状況にあわせた役割分担」と捉えて差し支えないです。
全て1人で行うのでなければ必ず役割分担をする必要がでてきます。
別の人が同時に同じコードを修正するようなことは基本的にあってはいけません。
モデル・ビュー・コントローラはその大枠であり、わけることにより、それぞれの役割がはっきりします。
オブジェクト指向もそう考えて差し支えないかと思います。

もちろん全て1つのクラスに詰め込むなり、クラスを作らずメソッドだけで乗り切ることも可能です。
でもそれは、「どこに何がどのような意図で存在する」というのを「作った人以外知らない。もしかしたら作った人すら数ヵ月後には覚えてない」ような状態となります。
質問者さんが仰る「フレームワークなしで長年推し進められてきたウェブサービスを一人で抱え込んだとき、その中身に散らかりっぷりに戸惑った経験があります」がまさにそれに近いのではないでしょうか。

きちんと役割分担がされていれば、その戸惑いも少なくなり、抱えたときに自身の役割に集中できるのではないでしょうか。

フレームワークを知っていると、このようなことがなくなり

ではなく「フレームワークでシステムが構築されていると」です。
幾らフレームワークを知っていても熟練者であっても何年もレガシーな状態で更新されてきたシステムを
全てフレームワークに置き換えるのは困難です（まれにそういう案件に出くわして辛い目にあいます）

フレームワークは比較的中規模なプロジェクト、もしくは自分以外のエンジニアが引き続き改修していく予定が初めからあるプロジェクトになって初めて威力を発揮するもので、フレームワークの利便性を感じることができるのは、チームプロジェクトの中のみということになりますか

ちょっとゴチャゴチャしていますね。
「レガシーシステムを全てフレームワークに置き換えるのは困難」と1つ前に書きましたが、
不可能ではありません。
ただそれはとても時間（とお金と人）がかかるものであり、それだけの労力をかけた上で、
それまでのレガシー状態を凌駕するほどのメリットが提案できれば置き換えることもあります。
レガシーでなくても様々な理由で（例えばバグやセキュリティリスク）元々載っていたフレームワークを
全て別のフレームワークに載せかえるようなことも頻繁に行われています。

プログラミングで作られたシステム自体は、「モノ」ではないのでそれ自体は劣化しませんが、
それを作る「ヒト」は日々衰えていくものですし、使う「ヒト」も入れ替わっていき、
技術は日進月歩で進化し、また抱えるリスクや脅威も変化していきます。
何も改修が永遠に行われないシステムなど皆無ですし、同じく自分以外のエンジニアが全く関わらないシステムも皆無です。
「作ったら終わり」のシステムは何1つなくて、むしろ作った後が大事です。

---

PHPでの提示が多いようなので、PHPで例えると、
PHP自体のバージョンのサポート切れによる対応などは今まさに迫っているものではないでしょうか（PHP 5.6は2018年末まで。参考：PHPのリリース日とサポート期限）
社内で使っているだけの仕組みならいざ知らず、全世界からアクセス可能なところに公開されているものでしたら、
サポート切れによる様々なリスクに対応するため、システムだけでなく言語自体もバージョンアップしなければなりません。
最新のフレームワークであればその辺りの対応もしていっていますし、フレームワークのバージョンアップによる違いのところだけを吸収できれば載せかえも容易です。

そういった「言語のサポート期限」といった面からもフレームワークを選択するメリットは大きいと私は思います。

---

というのを踏まえておそらく本題と思われる質問へ回答します。

フレームワークの利便性を理解するためにはチーム開発に参加する必要がありますか

利便性の理解自体はどこであろうとなんでろうと関係ないので、チーム開発に参加して初めて得られる・そうしないと得られない　という必要性はありません。
むしろ、利便性を理解してからチーム開発に入られた方が良いかと。順序が逆ですね。
チーム開発に参加するということは役割分担された上で成果が求められます。
勉強のために開発を行うわけではありません。顧客に満足していただきその対価をいただくためです。

だからといってチーム開発の経験がないからと恥ずかしいと思う必要もないと思います。
そういう機会に恵まれなかったとか、学生とか、個人でやってるとか　様々事情がありますしね。
質問者さんがどういう境遇の方か知りませんが、やり方は間違わないで欲しいな　と思います。
フレームワークをしっかり扱っていくにはそのフレームワークの根本である言語の知識・技術は不可欠です。
その知識・技術をきちんと身につけていけば、フレームワークのメリット（もちろんデメリットも）見えてくるのではないでしょうか。

あとは、自身の言語習得レベルとあわせてフレームワークへの理解を深めていければ良いと思います。

Comments

[退会済みユーザー]

無駄にアツい（きらいじゃないけど

[m.ts10806]

つい数ヶ月前に10年以上前に作られたPHPシステムの改修に短期間でのぞんだので、
自身の経験（というか愚痴）も入っちゃってますね。ここも反省・・。
結局納期との兼ね合いで書き方踏襲するしかなかったですけど。

motuoさんのコメントでタイトルにある質問に答えてないことに今更気づきました。

[motuo]

そうなんですよね。
本文を読んでいるとフレームワークの利便性を語りたくなりますが、タイトルが違うので回答に迷う…

[m.ts10806]

一応、両方に答えてみました。
かなりの勢いで答えてしまったので追記してますが、本来はどっちかに絞ってもらって、要件ハッキリしてもらってから回答すべきでしたね。

Answer 2

ん？

開発環境を揃える方法や、dbを操作する方法を初めから知っていた場合、最初からそっちを使った方が早いとすら思ってしまいます。

この考え方がまさに、フレームワークを使いましょう。ということですよ。
基本的には、同じフレームワークを使うのが前提で、いろんなフレームワークを使い分けるということは
しません。
ですので、一度覚えれば・・・それつかうのが楽だよね。

フレームワークの利便性を感じることができるのは、チームプロジェクトの中のみということになりますか。

多人数でやるほうが、より効果的ですが、一人チームでもメリットはあります。
便利な機能が追加されたり、俺々フレームワークよりも、利用者が多いということは
活用方法の事例が多いです。

Comments

[m.ts10806]

つらつらと長文書いてしまったことを反省・・。

[momon-ga]

こちらは、シンプルすぎるので・・・
詳しく書かれることは有用だと思います。

Answer 3

一口に「フレームワーク」といっても、それぞれに粒度が違ってきます。

とりわけ、PHP以外の多くの言語の場合は、純粋に「フレームワークなし」で書こうとすれば、HTTPやCGIとしてのやり取りから自分で書かないといけないので、工数がかかりすぎてしまいますが、「フレームワークなしのWebサービス」はそのレベルで書いてあった、ということでしょうか。

Comments

[maisumakun]

ということで、「フレームワークを使った開発」といっても、ExpressとLaravelでは使う意味が全く違ってきます。そのあたりをごちゃまぜにしたところで、有意な結論は出ないでしょう。

Answer 4

多人数で開発する場合は、フレームワークが個々の能力の差を埋めてくれます。
また、ほとんどのフレームワークは手順がドキュメント化されているため、
扱い方に関する学習をそれぞれで行うことが出来ます。

ただしこういう人はフレームワークを使うのに向きません。
・人の作った仕様に従うのが嫌い
・フレームワークに従った、ありきたりな構造では面白くない
・そもそも自分のやりたいことを実現するのに、逆に邪魔になる
・既存のシステムが受け入れられず、ブログを書くのにWordPressなんてとんでもないと考えている
・いっそ自分でフレームワークを作って、他人に使わせたい

私はだいたいそういう感じです。
他人のフレームワークを使わず、以下のようなシステムを作ってます。
https://diary.croud.jp/

Answer 5

データ処理、アルゴリズム、そしてアウトプットを分離して部品化しやすくして再利用性を高めて安定稼働を期待するのがMVCモデルの側面じゃないかと思います。

phpが柔軟すぎて、一本のソースにデータ処理、アルゴリズム、htmlコードがメタメタに絡み合って、
共通化できそうでできない処理が多数あるとメンテナンス性が悪いです。
また、システムの一部でもアウトソースする場合も理解の妨げになりかねません。

フレームワークに則って開発することで、
癒着を防いでシンプルな構造にすることでデバッグもしやすくなり、
生産性が高まるのだと思います。
また、ある程度セキュリティー対策も盛り込まれていることで、
いちいちエスケープ処理を仕込まなくても良くなりますし。

そうは言っても、
一人で開発してすべて自分の頭に収まる場合などは、
サクサクっと最小限のコードを書きたくなるのもわからなくもないです。
ですが、
数年後にそういうソースコードを自分で紐解くバカバカしさが時間の無駄なので、
他人にわかりやすく、自分にもわかりやすいスタイルとして
規約である程度拘束して行くことで
後々のメンテナンス性も高まっていくことを実感するでしょう。

間を取って、自前のミニマムなフレームワークを作っても良いかもしれません。
今どきのフレームワークが何かと大風呂敷で便利機能が多数備わっている反面、
ちょっと重たい気もしなくもないので。

Answer 6

お前は、誰かが作った象形文字で書かれた言語を良いと思うのか？

俺ならみんながよく使ってる言語が良いと思うけどな

つまり、一人で独り言を話すサイコパスならいいんじゃね？

様々な問題を解決してきた言語を共通認識として話せた方が面白いし
みんなにとっても読みやすい本にもなるだろうよ

お前しか読まない本を作るならフレームワーク使わなくていいぞ

Answer 7

結局、下記の文章を読んで納得することにしました

PHP軽量FrameworkのSlim3

フルスタックフレームワークはフレームワークとしてのRequestやResponse処理の実装はもちろんのこと、Auth認証やSession管理といったところや他色々なWebの実装で必要な機能をもともと用意してくれている。

なので、必要とするコンポーネント部品をフレームワーク利用者が作らなくても実装できる。
また、デザインパターンもMVCモデルを採用しているフレームワークが多く、Viewとモデルを分割できるので、拡張性が高く、バグも入りにくくなる。

また、LaravelではViewコンポーザなどを利用してViewの中にビジネスロジックを含まない実装が可能になっている。