1

新しいプロジェクトを開始する予定で、さまざまな Web フレームワークを評価しています。真剣に検討しているのですが、耐久性が心配です。

Web フレームワークを選択するとき、何を使用するかを決定するときに何を探す必要がありますか?

私が見ているフレームワークで気づいたことは次のとおりです。

  • 小さなコミュニティ。ユーザーリストには毎日数件のメッセージしかありません
  • 6 か月以上前の前回のリリース以降、「ニュース」ページにニュースがありません
  • 過去 30 日間に svn コミットはありません
  • 優れたドキュメントですが、wiki は以前のリリース以降更新されていません
  • 最新のリリースがまだ Maven リポジトリにない

これは公式に認可された Java EE フレームワークではありませんが、スタック オーバーフローに関するさまざまな質問への回答で、良い解決策として言及している人を何人か見てきました。

これがフレームワーク戦争に巻き込まれたくないので、私が見ているフレームワークを言うつもりはありません。リスクを評価する際に、プロジェクトのその他の側面を確認する必要があることを知りたいです。これは、ORM などの Java EE Web 以外の領域にも適用されるはずです。

4

4 に答える 4

3

いわゆる「死んだ」プロジェクトは、プロジェクト自体がしっかりしていて、あなたがそれを気に入っている限り、それほど危険ではありません。問題は、ライブラリまたはフレームワークが、必要と思われるすべてのことを既に実行している場合、それはそれほど大したことではないということです。安定したプロジェクトを立ち上げて実行する場合は、フレームワークについての検討を終了し (完了!)、Web アプリケーションのみに集中する必要があります。フレームワーク自体を毎月最新リリースに更新する必要はありません。

個人的には、プロジェクトにとって直感的なものを見つけることが最も重要なポイントだと思います。最も理にかなっていることは何ですか？MVC? URL の各要素は個別のオブジェクトにする必要がありますか? インタラクティブ性 (AJAX) はどのように機能しますか? それが「業界標準」である、または多くの有名なサイトで使用されているという理由だけで何かを選ぶのは意味がありません. たぶん、彼らはあなたとはまったく異なるニーズのためにそれを選んだのでしょう. 各フレームワークのチュートリアルを読んで、批判的になりましょう。それがあなたの考え方に合わない場合、またはそれがよりエレガントに行われているのを見たことがある場合は、先に進んでください。ここで考えているのはデザインです優れた設計は、柔軟性とスケーラビリティを維持することと同じです。新旧を問わず、すべての言語で何百もの Web フレームワークが存在します。あなたのプロジェクトで思い通りに機能するものが、きっと見つかるはずです。

私が必須と考えるポイント：

  • プラグインによる拡張: memcache、gzip、OpenID、AJAX の良さなど、さまざまなミドルウェア タスク用のプラグインが既に存在するかどうかを確認します。
  • シンプルさとモジュール性: 複雑になればなるほど、学習曲線が急になり、その安定性を信頼できなくなります。特定のテクノロジーに「ロック」されているほど、足首に鎖がかかる可能性が高くなります。
    • データベースにとらわれない: 開発に sqlite3 を使用してから、コードまたは構成を 1 行変更するだけで本番 DB に切り替えることができますか?
    • プラットフォームに依存しない: Apache、lighttpd などで実行できますか? クラウドで実行するように移植できますか?
    • テンプレートにとらわれない: テンプレート システムを切り替えることはできますか? 専任のデザイナーを雇い、彼らが本当に何か他のものを使いたがっているとしましょう。
  • ドキュメンテーション: オープンソースの場合はそれほど厳密ではありませんが、たとえば、独自のプラグインの作成方法を完全に理解できるようにするには、十分な公式ドキュメントが必要です。また、同じフレームワークを使用している作業サイトのソース コードがあるかどうかも確認してください。
  • ライセンスとソース コード: ソース コードにアクセスできますか? また、それを変更することは許可されていますか? 商用利用可能か検討！（現時点でそれを行う予定がない場合でも。）

全体として、柔軟性。4 つのポイントすべてに満足すれば、ほぼ完了です。そこには「死」について何もなかったことに注意してください。コアの設計が優れていて、やりたいすべての web-dev 3.0-beta バズワードを実行するための簡単にインストール可能なプラグインがある場合、最後の SVN コミットが 2006 年であったかどうかは気にしません。

于 2010-07-11T03:56:09.163 に答える
2

フレームワークを実稼働環境プロジェクトに使用することを決定する前に、フレームワークで探すものは次のとおりです。

  • よくレイアウトされ、書かれたドキュメントがたくさんあります。ドキュメンテーションが悪いということは、すべてがどのように機能するかを見つけようとして時間を無駄にしているということです。これは、クールな新しいマイクロ フレームワークなどで遊んでいる場合は問題ありませんが、クライアントの場合はそうではありません。

  • 質問などをすることができる適度な規模のコミュニティ。楽しくて活発な IRC チャンネルは大きなプラスです。

  • 製品の絶え間ない反復。バグは、毎日または毎週、クローズまたはオープンされていますか? おそらく良い兆候です。

  • フレームワークのコードを調べて、何が起こっているのかを理解できます。フレームワーク コードが優れているということは、プロジェクトが長期にわたって成功する可能性が高くなることを意味します。

  • 私はそれを扱うことを楽しんでいます。数時間遊んでいて、それが私の人生で最悪の時間である場合、クライアントのためにそれを使用することは絶対にありません.

私は続けることができますが、それらは私の頭の上から離れたいくつかの主要なものです.

于 2010-07-11T03:07:43.223 に答える
2

リスクを評価するときは、フレームワークを見るだけでなく、自分自身(および他のチーム メンバー)について多くのことを考慮する必要があります。

  • フレームワークが新しく未熟な「最先端」のフレームワークである場合、それをデバッグし、遭遇した問題を修正または回避する意思と能力はありますか?

  • 小規模なコミュニティの場合、このデバッグと診断の多くを自分で行う必要があります。それを行う時間はありますか？それでも締め切りに間に合いますか？

  • フレームワークの良さを判断するために自分でフレームワークを調べたことがありますか、それとも他の人がフレームワークについて言うことに頼る気がありますか? なぜ彼らの判断を信頼するのですか？

  • 「公式に認可された Java EE フレームワーク」ではなく、なぜこれを使用したいのですか? それは実用的な理由ですか、それとも単に何か新しいことに挑戦したいという願望ですか?

  • フレームワークの問題が原因で締め切りに間に合わなかったり、質の悪い製品を提供したりした場合、それについて上司や顧客にどのように話しますか?

于 2010-07-11T03:08:52.490 に答える
1

あなたが引用したすべての兆候は、フレームワークの選択にとって悪いニュースになる可能性があります.

他に探しているのは、Amazon などで入手できる本です。優れたドキュメントが利用可能であるということは、作成者はそれが牽引力を持っていると信じており、それを知っているユーザーを見つけることができるということです。

私が考えることができる唯一の救いは、相対的な成熟度です。フレームワークまたはオープン ソース コンポーネントが成熟している場合は、記述どおりに機能し、それ以上の拡張は必要ない可能性があります。

バグのないソフトウェアはありません (私のものを除いて) ため、活動の証拠を示すバグ トラッカーがまだあるはずです。ただし、その場合、要求が殺到する必要はありません。

于 2010-07-11T03:03:16.410 に答える