アカウント名:
パスワード:
1. 利用者数が少ないフレームワークは回避する。利用者が多いのは強いです。Stack Overflowを探せばあなたと同じ悩みを抱えていたひとがきっといます。PHPだったらCakePHPが無難でしょう。FuelやLaravelはパフォーマンスも高く、評価も良いですが、Cakeに比べたら利用者も少ない。同じプラットフォームであれば、Google Trendsで比べてみるのも良い手です。
2. 致命的な脆弱性が頻発するフレームワークは回避する。保守費用に含めるフレームワーク部分の保守コストを計算してみましょう。致命的な脆弱性が発見されると、あなたが納品した数だけコストがかかります。分かり易く言えば、Struts2は今すぐ滅びるべきフレームワークの筆頭ということです。
3. 人員のスケールアウトに耐えられるものを。ビジネスが拡大し、人員が増えたときのラーニングコストは馬鹿に出来ません。ドラクエで主人公を以外を全員転職させてしまった状況を考えてください。あまりに尖ったフレームワークやプラットフォームだと、大変困ったことになります。少数精鋭でビジネスを展開するのであれば、そこまで気にする必要はありませんが、チームメンバーが一人死んだとき、代わりの人材を確保するためのコストを考えておくことは有用です。
4. アプリケーションライフサイクルを考慮して。ビジネスに最適化されたフレームワークは、ある程度の期間は高い生産性を維持できますが、そのパフォーマンスを維持するにはフレームワーク自体をモダンに保つためのコストが高くなりがちです。自社専用フレームワークや、既製フレームワークをごっそりとチューンしたものは3.の問題にも直結する上、気を抜くと土台から腐っていくという大きなリスクがあります。やめておきましょう。あたながすべきことは、候補のフレームワークのライフサイクルが自分たちの仕事のやり方にどう影響するか、これを最初から考えておくことです。
PHPやJavaのフレームワークなんてどうなるか分からんよベースとなるブラウザですら一寸先は闇なんだから
あと言われんでもわかってる事を並べるのは無粋すぎる
> PHPやJavaのフレームワークなんてどうなるか分からんよでも消去法で選択肢を絞ることはできるだろ。PHPならSymfonyやZFのようなセンスの無い上に絶妙にモダンを履き違えたフレームワークを選んではいけないし、JavaならSpringのような脳味噌がXMLで出来たようなクズどもが作ったフレームワークを選んではいけない。そういうのは重要だよ。後々響くんだから。
モダンやXMLとやらは保守開発の工数に響く話であって、利用しているフレームワーク自体が今後どうなるか分からんという事それが今回の話実装センス程度で予測できるなら苦労はしない
んー?ダメなモノは結局そのうち淘汰されていくんだから、そこに注目してダメな選択肢を排除すれば、ハズレを引く可能性は下がるでしょ?それすらしないの?
例に挙げている、Symphony,ZF,Springは淘汰されたといえず、まだちゃんとメンテされている。
それよりももっとまともな設計のものではさっさと淘汰されるのがあるから、中身だけでなくて他に何を基準にすればいいのかってことでしょ。
つまりSymfony, ZF, Springについては、それぞれの言語の標準仕様に食い込む程の影響力を持ちつつ長い事生き残っているので、消去法で選ぶなら良い選択肢というわけですね。
でもZFとSpringは実際投資のされ方が全盛期に比べるとかなり残念な感じになってるからそこはリスク高めで考慮しないと。Symfonyはそれと比べると若干リスクは下でしょうけど、重量級FWとしてはCakeに完全に遅れてる上に微妙なので、ゆっくりと利用者が減っていくパターンだと思いますよ。
以前得た情報をアップデートする余裕が無い人は、選択肢が狭まって大変なんだなあ。
PHP使ってる時点でそれは考慮すべき項目から外れてるだろ?むしろ、PHPと心中出来るのはZF以外存在し得ないと言う点は無視出来ないだろ?
タレコミ読んだ?4つ全部考慮してもAdobe Flexの選択ミスは防げなかったでしょ。
> 2. 致命的な脆弱性が頻発するフレームワークは回避する。これに引っかかるよね?
PHP使えないな。
Adobe Flexが引っかかるくらい厳密に適用するんなら、長生きのQtも引っかかってる。結局、長生きのフレームワークを選ぶ役には立たないね。
1. 利用者数が少ないフレームワークは回避する。2. 致命的な脆弱性が頻発するフレームワークは回避する。
利用者が多くて脆弱性が頻発しないフレームワークってことですよね。明確な基準で良いんじゃないでしょうか。
フレームワークは、生ものです。すぐに腐ります。というか、生まれたときから腐ってます。また、不要な機能で重くなりがちです。ですから、フレームワークが変わっても大丈夫なように、独自に作りこむのが一番安上がりです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
ビジネスに合ったものを選ぶしか。あと消去法 (スコア:3, 興味深い)
1. 利用者数が少ないフレームワークは回避する。
利用者が多いのは強いです。Stack Overflowを探せばあなたと同じ悩みを抱えていたひとがきっといます。
PHPだったらCakePHPが無難でしょう。FuelやLaravelはパフォーマンスも高く、
評価も良いですが、Cakeに比べたら利用者も少ない。
同じプラットフォームであれば、Google Trendsで比べてみるのも良い手です。
2. 致命的な脆弱性が頻発するフレームワークは回避する。
保守費用に含めるフレームワーク部分の保守コストを計算してみましょう。
致命的な脆弱性が発見されると、あなたが納品した数だけコストがかかります。
分かり易く言えば、Struts2は今すぐ滅びるべきフレームワークの筆頭ということです。
3. 人員のスケールアウトに耐えられるものを。
ビジネスが拡大し、人員が増えたときのラーニングコストは馬鹿に出来ません。
ドラクエで主人公を以外を全員転職させてしまった状況を考えてください。
あまりに尖ったフレームワークやプラットフォームだと、大変困ったことになります。
少数精鋭でビジネスを展開するのであれば、そこまで気にする必要はありませんが、
チームメンバーが一人死んだとき、代わりの人材を確保するためのコストを考えておくことは有用です。
4. アプリケーションライフサイクルを考慮して。
ビジネスに最適化されたフレームワークは、ある程度の期間は高い生産性を維持できますが、
そのパフォーマンスを維持するにはフレームワーク自体をモダンに保つためのコストが高くなりがちです。
自社専用フレームワークや、既製フレームワークをごっそりとチューンしたものは3.の問題にも直結する上、
気を抜くと土台から腐っていくという大きなリスクがあります。やめておきましょう。
あたながすべきことは、候補のフレームワークのライフサイクルが自分たちの仕事のやり方にどう影響するか、
これを最初から考えておくことです。
Re: (スコア:0)
PHPやJavaのフレームワークなんてどうなるか分からんよ
ベースとなるブラウザですら一寸先は闇なんだから
あと言われんでもわかってる事を並べるのは無粋すぎる
Re: (スコア:0)
> PHPやJavaのフレームワークなんてどうなるか分からんよ
でも消去法で選択肢を絞ることはできるだろ。
PHPならSymfonyやZFのようなセンスの無い上に絶妙にモダンを履き違えたフレームワークを選んではいけないし、
JavaならSpringのような脳味噌がXMLで出来たようなクズどもが作ったフレームワークを選んではいけない。
そういうのは重要だよ。後々響くんだから。
Re: (スコア:0)
モダンやXMLとやらは保守開発の工数に響く話であって、
利用しているフレームワーク自体が今後どうなるか分からんという事
それが今回の話
実装センス程度で予測できるなら苦労はしない
Re: (スコア:0)
んー?
ダメなモノは結局そのうち淘汰されていくんだから、そこに注目してダメな選択肢を排除すれば、
ハズレを引く可能性は下がるでしょ?
それすらしないの?
Re:ビジネスに合ったものを選ぶしか。あと消去法 (スコア:1)
例に挙げている、Symphony,ZF,Springは淘汰されたといえず、まだちゃんとメンテされている。
それよりももっとまともな設計のものではさっさと淘汰されるのがあるから、中身だけでなくて他に何を基準にすればいいのかってことでしょ。
Re: (スコア:0)
つまりSymfony, ZF, Springについては、それぞれの言語の標準仕様に食い込む程の影響力を持ちつつ
長い事生き残っているので、消去法で選ぶなら良い選択肢というわけですね。
Re: (スコア:0)
でもZFとSpringは実際投資のされ方が全盛期に比べるとかなり残念な感じになってるからそこはリスク高めで考慮しないと。
Symfonyはそれと比べると若干リスクは下でしょうけど、重量級FWとしてはCakeに完全に遅れてる上に微妙なので、
ゆっくりと利用者が減っていくパターンだと思いますよ。
Re: (スコア:0)
以前得た情報をアップデートする余裕が無い人は、選択肢が狭まって大変なんだなあ。
センスを言うか? (スコア:0)
PHP使ってる時点でそれは考慮すべき項目から外れてるだろ?
むしろ、PHPと心中出来るのはZF以外存在し得ないと言う点は無視出来ないだろ?
Re: (スコア:0)
タレコミ読んだ?
4つ全部考慮してもAdobe Flexの選択ミスは防げなかったでしょ。
Re: (スコア:0)
> 2. 致命的な脆弱性が頻発するフレームワークは回避する。
これに引っかかるよね?
Re: (スコア:0)
PHP使えないな。
Re: (スコア:0)
Adobe Flexが引っかかるくらい厳密に適用するんなら、長生きのQtも引っかかってる。
結局、長生きのフレームワークを選ぶ役には立たないね。
Re: (スコア:0)
1. 利用者数が少ないフレームワークは回避する。
2. 致命的な脆弱性が頻発するフレームワークは回避する。
利用者が多くて脆弱性が頻発しないフレームワークってことですよね。
明確な基準で良いんじゃないでしょうか。
Re: (スコア:0)
フレームワークは、生ものです。すぐに腐ります。というか、生まれたときから腐ってます。
また、不要な機能で重くなりがちです。
ですから、フレームワークが変わっても大丈夫なように、独自に作りこむのが一番安上がりです。