パスワードを忘れた? アカウント作成
10127716 story
ビジネス

生き残るフレームワーク、どうすれば選択できる? 145

ストーリー by headless
選択 部門より
本家/.「Ask Slashdot: How Do You Choose Frameworks That Will Survive?」より

私は小さなソフトウェア開発会社で指導的立場にあり、購入を含めてツールの選択にも責任がある。しかし、チームで使用するフレームワーク、特にUIフレームワークを選択するのは非常に難しい仕事だ。数年前、将来のWeb開発に向けてリッチインターネットアプリケーションフレームワークを選択した際、自分の調査ではAdobe Flexが最適と思われた。AdobeがLinuxバージョンのFlashを廃止することが想像できなかった頃の話だ。当時HTML5は初期の計画段階だったのに対し、Flexは完成度が高く、ドキュメントも豊富な商用製品であり、Flashを使用するための優れた機能が搭載されていた。そのため、Flexを選択したが、現在では開発が停止している。逆に、15年前にデスクトップアプリケーションをQtに切り替えたが、こちらは現在も広く使われている。そこで、私は正しい選択と誤った選択の違いを見出したいと思っている。Qtは設計がよくできていたのかもしれないが、私の評価が正しいかどうかはわからない。今のところ、自分の経験をもとにした長期にわたって使用できるツールの選択を助ける適切な決定木はみつかっていない。このことについて、尊敬する/.諸氏から役立つ情報が得られるのではないかと期待している。失敗のない原則を見つけることは可能だろうか。

(続く...)

当時はAdobeのような大企業の製品がオープンソース化されるとは思わず、Flexには多額の投資をした。しかし、数年後にFlashのLinuxサポート終了が発表され、投資は無駄になってしまった(今回の議論とは無関係なので理由は説明しないが、うちの会社ではLinuxサポートが非常に重要だ)。Adobe Flexと前後して、FlashとDHMLを切り替えて出力可能なOpenLaszloも試していた。今となってみれば、当時の印象とは異なり、こちらのほうがよい選択だったような気もする。 同じようなことは、クラシックPHPにかえて選択したCodeIgniterでも起こっている。CodeIgniterを使うためにTesla Model Xが買えるほどの金額を投資したが、現在では開発元のEllisLabが売却先を探している状況だ。

現在もPHPフレームワークとしてLaravelを押す人や、他の提案をする人がいて、私は再び岐路に立たされている。そのため、起こり得る将来の失敗をどうすれば避けることができるか悩んでいるところだ。実際のところ、ツールが生き残るかどうかを予測するのは不可能なことのようにも思える。過去の決定の中には失敗したものもあるが、再考してみると当時はすべてが適切な選択だったと思われるのだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2013年10月27日 17時00分 (#2485050)

    ITエンジニアなんかやってないで株買って大儲けできるよ。

  • わからない (スコア:3, 興味深い)

    by deleted user (13014) on 2013年10月27日 17時17分 (#2485061)

    JavaFX2 なんてものがあるのか、まあ誰にも相手にされずに終わるだろう、ということを確認するためにググったとき読んだこの文章 [oracle.com]のグラフ [oracle.com]が、分かりやすく現状を示しているように思えます。HTML5 は素晴らしいが、どう作るかについては、いまだ試行錯誤のまっただ中。

    JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。LAMP Stack は書きづらいだけ。使う理由がなくなった。シングルページアプリケーションの利点がはっきりしてきた今となっては、たぶん MEAN Stack [youtube.com] が最高に近い形に見えます、が、Dart だの、Type Script、オフラインアプリケーション、いろんな方向から新しいコンセプトが次々出てくるときになにが最善かわかりようがない。

    (その点、iOS や Android は簡単でいいですね。OSが提供する API を使う以外に選択肢がない。はっきりしていていい)

    • by Anonymous Coward

      > JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。

      それはないです。

      見た目重視のB2Cではなく、実用重視のB2Bや自社内業務アプリなどでは、
      JavaScriptに頼ったUI実装は無駄なコストやブラウザ変更時の負荷を非常に増大させるだけです。
      特に責任の分界があるようなシステムでは、可能な限り「自分の腹の中で」処理をし
      相手のブラウザにはなるべく仕事をさせない必要があります。
      これはビジネスの話ですので、実装の都合などより上のレイヤーです。

      • by deleted user (13014) on 2013年10月27日 18時28分 (#2485093)

        JavaScript に頼った実装で問題ない、というのがここ五年間の中で理解しなければならない重要な変化だと思います。ブラウザ変更で動きが大きく変わるというのは、過去の話。さすがにもう PHP は要らないと言わせてください(笑)

        親コメント
        • by Meth610 (31617) on 2013年10月27日 20時42分 (#2485153)

          JSのひとつの問題としてセキュリティがあります。
          つまりユーザー側でコードや変数の書き換えが好き勝手にできる。
          ゲームで言えばチートし放題。ChromeにはJSコンソールというチート機能が標準搭載。

          そこで質問ですが、JSオンリーで書かれたネットバンクサービスとか、使いたいですか?

          親コメント
          • by Anonymous Coward on 2013年10月27日 21時05分 (#2485165)

            JSだろうがHTMLだろうが、結局HTTPしゃべってるだけなんだから、
            そんなん自由にユーザ側で書き換えできることに大差ないだろ?
            別にユーザ側から好き勝手なHTTP送られても、サーバー側のValidationが機能要件を満たしていれば関係なくね?

            親コメント
        • by Anonymous Coward on 2013年10月27日 19時29分 (#2485115)

          ないわー。
          jQueryを使おうが、JavaScriptを使う限りブラウザ間の互換性・挙動の違いに振り回される。
          ましてやPHPが要らないとか、本気で業務アプリ作ってるのと言いたくなります。

          時代の変化はありますが、それが全てを解決した訳でもないし、エンドユーザーに対して「このブラウザ以外は動作しません。ご了承ください。」と
          動作環境を押し付けられる訳でもない。

          個人で趣味で作るようなものならともかく、対顧客ありきのシステム構築で「JavaScriptに頼ったUIが最適」とか意味わかりません。

          親コメント
        • by Anonymous Coward on 2013年10月27日 20時11分 (#2485136)

          これには反対1票

          組み込み系で、複数のブラウザ+独自機器をサポートしています。
          JavaScriptに頼った場合、貧弱なマシン、独自機器での表示パフォーマンスが
          極端に落ちるのが現状です。

          あと、特定のブラウザでの不具合回収時の、再確認も、
          サーバサイド側での対応のほうがやりやすいです。

          表示がリッチになればリッチになるほど、サーバサイド側で、
          必要な情報を出力するほうがよいというのが、
          昨年まで作っていたシステムでの結論です。

          コソコソAC

          親コメント
      • by Anonymous Coward

        今作ってる某社の社内システムがまさにクライアントサイドJavaScriptバリバリで、サーバはJSONを返すだけという変態システムなんだが。
        # 超AC

        • by Anonymous Coward on 2013年10月27日 19時42分 (#2485123)

          8年くらい前になるか、某プロバイダのWebメール新版を作るとき、Outlookを目指してAjax/JSONバリバリでやったなぁ。
          Ajaxの技術書も限られてて、結構難産だったけど、動作の組み立てよりも軽量化に腐心した記憶ばかり蘇る。
          それでも「重い」「使いづらい」と不評だったけど。

          クライアント側はその頃からさらに代替わりしてるけど、鯖側は我々が作ったものを引き継いだと聞いた。

          「ここ五年間の」ということは、やはりちょっと早かったのかな…。

          親コメント
        • by Anonymous Coward

          実用重視なら、余計にJSは使うと思うんだけど、#2485073の人は、装飾用途でのJSしか知らないのかしら。
          HTMLページを一Pづつ開くより、Ajaxで必要な部分だけ書き替えたほうがずっと負荷が少ない。

        • by Anonymous Coward
          今時、ほとんどのシステムがそうなんじゃないですかね。
          サーバー側は、JSONベースのAPIさえ定義できれば、比較的、UI側の人と分業がしやすいので従来よりは開発が楽になったと思っています。
          いざとなれば、JSONを喋るリッチクライアントも作れますし、
          セキュリティやユーザーサイドを信用できるかどうかといった議論さえしっかりできれば非常によい傾向だと思っています。
  • by Anonymous Coward on 2013年10月27日 17時51分 (#2485078)

    1. 利用者数が少ないフレームワークは回避する。
    利用者が多いのは強いです。Stack Overflowを探せばあなたと同じ悩みを抱えていたひとがきっといます。
    PHPだったらCakePHPが無難でしょう。FuelやLaravelはパフォーマンスも高く、
    評価も良いですが、Cakeに比べたら利用者も少ない。
    同じプラットフォームであれば、Google Trendsで比べてみるのも良い手です。

    2. 致命的な脆弱性が頻発するフレームワークは回避する。
    保守費用に含めるフレームワーク部分の保守コストを計算してみましょう。
    致命的な脆弱性が発見されると、あなたが納品した数だけコストがかかります。
    分かり易く言えば、Struts2は今すぐ滅びるべきフレームワークの筆頭ということです。

    3. 人員のスケールアウトに耐えられるものを。
    ビジネスが拡大し、人員が増えたときのラーニングコストは馬鹿に出来ません。
    ドラクエで主人公を以外を全員転職させてしまった状況を考えてください。
    あまりに尖ったフレームワークやプラットフォームだと、大変困ったことになります。
    少数精鋭でビジネスを展開するのであれば、そこまで気にする必要はありませんが、
    チームメンバーが一人死んだとき、代わりの人材を確保するためのコストを考えておくことは有用です。

    4. アプリケーションライフサイクルを考慮して。
    ビジネスに最適化されたフレームワークは、ある程度の期間は高い生産性を維持できますが、
    そのパフォーマンスを維持するにはフレームワーク自体をモダンに保つためのコストが高くなりがちです。
    自社専用フレームワークや、既製フレームワークをごっそりとチューンしたものは3.の問題にも直結する上、
    気を抜くと土台から腐っていくという大きなリスクがあります。やめておきましょう。
    あたながすべきことは、候補のフレームワークのライフサイクルが自分たちの仕事のやり方にどう影響するか、
    これを最初から考えておくことです。

    • by Anonymous Coward

      PHPやJavaのフレームワークなんてどうなるか分からんよ
      ベースとなるブラウザですら一寸先は闇なんだから

      あと言われんでもわかってる事を並べるのは無粋すぎる

      • by Anonymous Coward

        > PHPやJavaのフレームワークなんてどうなるか分からんよ
        でも消去法で選択肢を絞ることはできるだろ。
        PHPならSymfonyやZFのようなセンスの無い上に絶妙にモダンを履き違えたフレームワークを選んではいけないし、
        JavaならSpringのような脳味噌がXMLで出来たようなクズどもが作ったフレームワークを選んではいけない。
        そういうのは重要だよ。後々響くんだから。

  • それがGeekってもんだろ

    # と言いたいところだけど企業だとそうもいかないだろうな
    # といっても5年前にもてはやされてたフレームワークでいまも生きてて今後も数年にわたってつかえそうなものを
    # ピックアップしてみると何か見えるものがあるかもしれない・・・気がする・・・かも・・・

  • by Anonymous Coward on 2013年10月27日 17時17分 (#2485060)

    何言ってるんだよと言われるとは思いますが、本気で一つのフレームワークと付き合う気があるならOSSの中で選ぶのも良いと思います。
    クローズドな製品と違って、OSSなら開発が止まろうとやる気にさえなれば自力でメンテすることができます。
    「CodeIgniterを使うためにTesla Model Xが買えるほどの金額を投資」するような会社なら、自力メンテを視野に入れてもいいんじゃないでしょうか。
    内製で作るよりもスタートアップのコストが削減できますし、Linuxサポートが重要になる会社ならOSSとの付き合い方にも慣れてるでしょうし。

  • by Anonymous Coward on 2013年10月27日 17時23分 (#2485064)

    世の中は、長期的に安定した流れがある一方で、時々ブレークスルーのような不連続的な変化があるので、確実に予測することは難しい。

    だから、どのフレームワークが生き残るかは分からないという前提で、設計をするべきである。
    デザインパターン等で、フレームワーク部分依存とそうでない部分を分離することは技術的に可能であろう。

    ただ、検討した結果、フレームワーク依存しかないというなら諦めるしかない。それは、他人のふんどしで相撲をとるビジネスを選択してしまった報いなのだから。

  • ザックリと仕様を書けばHTML・CSS・PHP・Javascript・SQLなどの最適な組合わせでフレームを出力してくれるようなものがあれば素晴らしいのだが・・・
  • 「新しいものにホイホイ飛びつかない」
    これは、昔から言われている話です。
    新しいものは致命的なバグが有ったりして、バッドノウハウが必要になったり。
    大勢が決するまで傍観して、既存のフレームワークを使い続ければ良いんじゃないかと。

  • by Anonymous Coward on 2013年10月27日 16時47分 (#2485045)

    オレの書いた奴使っとけばいいんだよ!
    他人の作ったライブラリなんかアテにならねっての!

  • by Anonymous Coward on 2013年10月27日 17時07分 (#2485054)

    フレームワークの話ではないが
    自分が面白いと思ったゲームは必ず売れている。
    自分がつまらないと思ったゲームが売れていることも当然あるが、ここで重要なのは面白いと思ったゲームが「必ず」売れている所。
    自分が面白いと思って外れたゲームは今の所存在しない。
    ちなみにゲーム歴は30年近く、コンシューマだけではなくPCとか最近ではソシャゲ等、ジャンルは多岐にわたりプレイ総数は1000や2000を軽く超えるだろう。
    その数千のうち、面白いと思ったゲームは必ず売れているわけだ。※予め売れる予想がたつ大作シリーズ等を除いても
    というわけで、自分が選ぶ物は世間に受け入れられる物だという認識をしている。
    フレームワークでも同じで、結局使われていくものは世間に受け入れられる物なのだから
    こういう自分自身の経験則や実績によって判断すればいいのではないだろうか。
    逆に自分が選んだ物はいつもすぐ消えていく、という実績があるのであれば、自分とフィーリングがあった物を使わなければいいという選択肢ができる。
    運が悪い奴はその反対をすればいいんじゃね理論である。
    自分に絶対的な自信があるか、もしくはないかどちらでも対応できる。
    中途半端に平凡だと反対にしても平凡なので通用しないが。

    • 自分に絶対的な自信があるか、もしくはないかどちらでも対応できる。
      中途半端に平凡だと反対にしても平凡なので通用しないが。

      もし、そんなに自分に自信を持っているんだったら、こんな相談はしないと思われる。

      その数千のうち、面白いと思ったゲームは必ず売れているわけだ。

      その数千はどうやって選んだ? レビュー誌とかネットの評判で選ばなかった?

      親コメント
  • by Anonymous Coward on 2013年10月27日 17時43分 (#2485075)

    もしそんな原則が存在しうるなら、
    Microsoftあたりが何としてでも見つけ出して、
    自社製品が生き残るようにしているでしょう。

    そんな原則は存在しないことを前提に、
    その場合に最適な設計、
    つまりフレームワークの切り替えを前提とした設計を導入するのが、
    もっともよい選択肢でしょうね。

  • by Anonymous Coward on 2013年10月27日 18時09分 (#2485087)
    自分が選んだ物では無い全てを、デスブログで取り上げて貰えば叶うかもしれない。
  • by Anonymous Coward on 2013年10月27日 18時16分 (#2485090)
    直接フレームワークさわったわけではないけど関係のある学校の利用してるCMSがNetCommonsです。
    XOOPSの独自拡張という段階で嫌な予感がしましたが以下のように変化していったのでした。
    Ver.1 XOOPS
    Ver.2 Maple *いわゆるStable
    Ver.3 CakePHP
    とフレームワークがかわっています。きっと次はうまくやってくれるでしょう。

    # ZAPZAPZAP
  • by Anonymous Coward on 2013年10月27日 19時20分 (#2485108)

    WindowsだとQtとかwxWindowsとかboostみたいな巨大ライブラリはDLLだとパスが関係してきたりするし、
    静的リンクにするにはサイズが大きかったりと扱いづらいと感じます。

    特に、最近は64bitプラットフォームが一般化してきて32bitだけ入れとけばいいと言う訳にはいかなくなってきたので、
    適切なプラットフォーム用のDLLを読ませるためにアプリと同じディレクトリに入れたりすると共有ライブラリの意味が薄らいでしまうし、
    DLL名の衝突を避けられる置き場所が限定されるので共有ライブラリ化には疑問を持っているのですが、
    ビルド済みのライブラリの配布はDLLになっていることが多いですね
    (DLLを使用する設定がデフォルトだったり静的リンクにするとCのランタイムも静的リンクになってしまうとか)。

    フレームワークにも新機能を追加していくから、一度組み込まれた物は簡単に外すことができなくてさらに巨大化してしまうというのもあります。

  • by Anonymous Coward on 2013年10月27日 19時40分 (#2485122)

    フレームワークなんて、ただ生き残ればよいって訳でないし、どれを選べば問題が少ないなんて予測できないだろうし、
    PHPみたいに生き残ってるのが困るんだよみたいなのもあるし、
    最終的になくなるケースでも移行先が準備万端とか、最初から移行しやすい構成に設計されてるとかあるだろうし。

    自分で特に推したいものが無ければ、信頼できるメンバに情報出させて、その後みんなで投票するぐらいの方が正解に近いかもしれんよ。
    選択候補には「特に希望はない」も含めておいて。
    メンバも納得して仕事できるし、自分だけの責任にならないし。

typodupeerror

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」

読み込み中...