Q&A
maisumakun様
お返事が遅れ申し訳ありません。
ご回答有難うございます。
普通の環境においては、やはりデメリットしかないものなのですね。。
ちなみに「特殊な環境」とはどのようなものがあるのでしょうか。
以前ある会社の方にお話し伺ったりした際に、このFWしか○○というDBに対応してないから採用した、というような話があったりしたのですが、そういうようなものなのでしょうか。
主題
PHPにおいて、独自フレームワークを採用するメリットを教えてください。
前提
新しく配属されたプロジェクトで、PHPの独自フレームワークが採用されていました。
中身は。。。CakePHPやLaravelなどを触れてきた身からすると、お世辞にも使い勝手の良いものとは思えませんでした。
- プログラム行頭のinclude祭り
- MVCになってはいるが、Mに分けきれていないビジネスロジックがCにも書かれているせいで重い
- MがDAOパターンになっていて、行数がとんでもないことになっている
=>ORマッパー的なものも無いので、SQLを実行するのにいちいちDAOにSQLを直書きしなければならず、非常に悪手に感じる - 至る所でglobal宣言されている
- 実証はしていないが、セキュリティ的に良いのこれで？という書き方が散見される
=>プリペアドステートメントを使わずヒアドキュメントやsprintfでSQLを作る、など
etc...
結構な大規模システムなので、正直なところ、OSSのフレームワークを使っていればもう少しマシだったのでは？と思ってしまいます。
PHPのバージョンがえらく古い（5系の初期の方）なので、OSSのフレームワークが動かない、というのはあるのかもですが。
初めて担当させて頂いたプロジェクトでもやはり独自フレームワークのシステムがあり、メソッドの引数が30個以上あるとか、画面に1項目追加するだけなのに8ファイル更新しないといけない、など酷い目にあったので、独自フレームワークには正直良い思い出がありません。
聞きたいこと
- 独自フレームワークと採用するメリットを教えてください。
=>小規模なシステムをサクッと作るだけならともかく、大規模システムで採用するメリットが分かりません。
=>OSSの方がめぼしい脆弱性はあらかた潰されているのでは？独自フレームワークだと、それを一から自分で潰さないといけないのでは？と思ってしまいます。 - OSSのフレームワークを使わない理由としては、どのようなものがあるのでしょうか。
=>フレームワークを覚えるのが大変だ、というのはあるのかもしれませんが、それを開発効率やセキュリティ面とトレードオフにするようなものなのでしょうか。
その他、いろいろあればそちらもご教授頂きたく。
当方まだエンジニア歴2年（開発に至ってはまだ1年です）なので、この辺りをいろいろ知っておきたく今回質問させて頂きました。
何卒、ご回答頂けますと幸いです。
よろしくお願い致します。
回答9件
0
ベストアンサー
私見ですが。
独自フレームワークのメリット
- フレームワークを作る、という点においてのみ、エンジニアの技術力があがります。ただし、独自フレームワークなんて使うだけであればエンジニアとしてなんの成長もありませんのであくまで作るの場合のみです。
- 責任の在り処が必ず特定できます。ただし、担当作業者が今も現場に居ればですが。
- そのフレームワークを作ったのが外部の人間であれば、利権にからむ癒着が生まれます。上の人は美味しい思いをしているかもしれません。
独自フレームワークのデメリット
- 基本的にsaken649さんの考察通りです。セキュリティ面、保守性、車輪の再開発の無駄、どこを取ってもデメリットだらけです。
OSSのデメリット
- 使用するフレームワークの仕様に振り回される可能性があります。
- 問題が起きたとき責任追及先がOSSになる可能性があるので、被害は泣き寝入りとなります。
なぜ独自フレームワークを使う(使っている)かの理由の推測
- PHP5の初期、ということはおそらく2004年以降かと思います。しかしその頃には企業レベルで採用されているPHPフレームワークはほとんど存在しておらず、フレームワークというもの自体認知されていなかった可能性があります。
http://www.phppro.jp/article/framework/history.php
- その状態で始動したプロジェクトで頑張って独自フレームワークを作ったとします
- それから13年、いまでは立派なカオスです。
誰かが途中で「フレームワークに乗り換えよう」と言っても、「誰がその乗り換えコスト払うねん」と一蹴されたことでしょう。なぜなら「乗り換え作業により生まれた空白の時間、バグの発生」の責任を誰が取るのか、という呪いがあるからです。
OSSのフレームワークを使わない理由としては、どのようなものがあるのでしょうか。
=>フレームワークを覚えるのが大変だ、というのはあるのかもしれませんが、それを開発効率やセキュリティ面とトレードオフにするようなものなのでしょうか。
理論的に言えばおっしゃる通りです。しかし、大抵の場合「決裁者」は責任を負いたくないので、乗り換えに躊躇するものです。今動いているんだからいいだろう、という事なかれ主義ですね。
もしあなたが本気でフレームワークの導入を訴えるのであれば、以下のいずれかが必要となるでしょう。
- 乗り換えにかかるコストの算出と、乗り換えずにいた場合の長期的に見たコスト、リスクのまとめとプレゼン資料
- 現状のフレームワークの致命的バグを見つけ出し、一新する機会を生み出すこと
- あなたが決裁者になること
投稿2017/10/24 04:26
総合スコア9206
0
独自フレームワークを採用するメリットを教えてください。
特殊な環境で特殊な処理が必要になるなら、自前で組んだほうがいい場面があるかもしれません。一般的なWebアプリケーションを作る上では、（合ったフレームワークを使うのと比べれば）デメリットしかありません。
なお、「Mに分けきれていないビジネスロジックがCにも書かれている」のは一般的なフレームワークでも起きがちな問題で、オレオレだからという問題でもないです。
OSSのフレームワークを使わない理由としては、どのようなものがあるのでしょうか。
おそらくですが、意図して「オレオレフレームワーク」を作ったというよりは、すでに合った簡素なプログラムに拡張を繰り返すうちに、フレームワーク的なものが出来上がっていた、というのが現実なのではないかと思います。
投稿2017/10/24 04:15
総合スコア145183
0
昔から（まだ OSS フレームワークがないころから）使っていたから、というのはあるでしょう。
また、OSS フレームワークを導入すると、OSS フレームワークのサポート切れがシステム寿命を左右してしまうという問題が発生します。何か致命的なセキュリティ問題があっても、期限切れでサポートされていなければ対応が面倒なことになります。
※また困ったことに OSS フレームワークだと、メジャーバージョンが変わると移行がすんなりいかなかったりする
それらを加味して、自前で作るほうがメリットがあると判断される場合もあるということです。自前であれば自分たちの責任でメンテし続けることができるのですから。
投稿2017/10/24 04:22
総合スコア13703
tacsheaven様
お返事が遅れ申し訳ありません。
ご回答有難うございます。
自前で作る方が自分たちの責任でメンテし続けられる、という考え方は確かに一理ありますね。。
0
#独自フレームワークのメリット
どの OSS フレームワークでも、10年も前のフレームワークはメンテナンスされていません。（少なくともメジャーバージョンは変わり、入れ替えを必要としています）
ので、そのメンテナンスが継続されていることが最大のメリットかと。
また、繰り返し行われる開発内容を、一般化して組み込むことがフレームワークのもととなるので、「フレームワークを作成するモノにとって」繰り返し開発することが避けられることもメリットだと思います。
#OSSのフレームワークを使わない理由
すでに回答にある以外では、10年以上に渡る長期メンテナンスに耐えうるモノではないという判断ではないでしょうか。
#注意
まぁ、上記は正常に独自フレームワークが正しくメンテナンスされているということが必須条件になります！
個人的にはフレームワーク以前の箇所に問題が発生している事を放置していることのほうが重大だと思います。
OS やミドルウェアのバージョンアップとともに、フレームワークの入れ替えを提案すべきかと。。。
投稿2017/10/24 06:28
退会済みユーザー
総合スコア0
te2ji様
お返事が遅れ申し訳ありません。
ご回答有難うございます。
正しくメンテされているならば、他の方も仰ってましたが自分たちの責任でメンテが続けられるから、というのは大きなメリットでしょうね。。
問題は山積み過ぎるんですが、いかんせんシステム規模がデカ過ぎるので、現状の範疇でどうにかします。。
0
OSSのメンテンナンスに関しては、昔は個々で独自に管理されていたものが近年はほぼGitHubかそれに類するものに統一されて、ソーシャルコーディング等の文化も確立されているので、必要であれば保守開発を引き継いだり、新バージョンへの移行支援をしたりといったことも敷居は低いかと思います。
独自フレームワークの発展が公開により様々な利用によって、より洗練されたOSSフレームワークになったとみなすこともできます。
リスクとしては、Struts2のように後々になって問題点が出てきた機能上の仕組みに対して、攻撃コードが即全世界に出回って、アングラビジネス等の矛先に向けられる点は近年より配慮が必要かと思います。
投稿2017/10/24 22:11
総合スコア4106
aro10様
お返事が遅れ申し訳ありません。
ご回答有難うございます。
OSSの攻撃リスクというのは確かにありますね。。。
最近だとPHPMailerの件も騒動になっていましたね、そういえば。。
Struts2に関しても、PHPerの私でさえStruts2のバグがーという話を聞くくらいなので、相当なインパクトだったのでしょう。。
0
前略。
私も独自FW使ってる会社ってここ最近では全く聞かないですねえ。昔は渋谷にある企業が独自FW作って云々って話はよくありましたが。
メリットは技術や権利問題をあまり気にしなくていいっていうのはあると思います。じゃあ汎用ライブラリまで全部作るのか？っていうと微妙だと思いますが。
PHPで作るレベルなら、確かに0.0.1違っただけでも大きく変わることがあるOSS-FWですが、それでも使った方が工数や管理のし易さは断然上だと思ってます。特に同じ技術者がサービス終了までずっといるわけではない世界ですからね。
他の方と同意見といえば過言ですが、独自FW使うメリットは今となってはほぼ無いと思います。
投稿2017/10/24 14:43
総合スコア152
kpluplus様
お返事が遅れ申し訳ありません。
ご回答有難うございます。
やはり今はOSSをいかに使うか、という方に焦点が当たっているんでしょうね。
React.jsみたいなことになると少し厄介ですが、そもそも権利関係をそんなに気にしなくていいのがOSSだと思っていたのですが。。
0
書かれている内容を拝見し、色んな歴史と背景がありそうだなと思いました 笑
フレームワークが検討されていた当時がどんな状況だったのかにもよりますが
恐らく当時はOSSのFWだけでは足りない機能や、システムの中で共通化できる機能などが多くあったため
ラッピングするような形で独自FWを作ったのではないかと思います。
そういう大規模プロジェクトは何個か見たことがあります。
多くの場合、ベンチャーよりかはベンダーやメーカー系に多いのではないでしょうか。
そうなると政治的な力が働いている場合もあります。
（例えば、開発を請け負うことが決まっているA社が独自FWを持っていて
開発効率アップできると提案する。等。）
大規模だからこそ共通部品を使う（それをFWとする）ことで
全体の工数を削減できるということは意外とある話です。
ただ、それは開発当初の話であり、まさにそちらのプロジェクトのように
年数が経てば経つほど、OSS FWが進化する一方メンテされずにガラパゴス化するのもあるあるです。
現在だけを見るとメリットはほとんどなくなっているのではないでしょうか。
検討されていた当初はきっと、それが大きなメリットになると考えられていたのだと思います。
投稿2017/10/24 04:25
総合スコア928
yuki-saito様
お返事が遅れ申し訳ありません。
ご回答有難うございます。
政治的な力、というのは確かにあるのかもしれません。
どういう経緯でそのベンダーが選ばれたのかは知る由もありませんが、確かに大きい会社ではあるので。。
恐らく色々あったのでしょう。
今となってはsaken649さんが感じるようなことしか残っていないんでしょうね・・・
そういうプロジェクトはたくさんあると思います。
（私も過去にそういうプロジェクトを何個も経験したので。）
0
セキュリティ上で問題があると強固に主張し、乗り換えましょう。
その際、バグは必ず出るので、責任が追及された時のために、乗り換えることのビジネス上のメリットを説明して乗り切りましょう。
投稿2018/12/17 22:14
総合スコア39
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/10/24 04:48
2017/10/24 04:54
2017/10/27 08:29
2017/10/27 08:32