【私見】PHPフレームワークはどう選ぶ？

PHP フレームワークを選択するにはどうすればよいですか?

この質問は私にとって面接でよくある最初の質問なので、SF でこの質問を見たとき、時間をかけて答えました。ここでいくつかの豆知識と追加を示します。

多くの場合、問題について議論するときは、コンセプトから始めることをお勧めします。フレームワークは、プロジェクトの初期段階でチームによって選択された開発フレームワーク、または長期の開発プロセス中に洗練された共通ロジックです。したがって、初期段階でフレームワークを選択する場合でも、途中でリファクタリングしてフレームワークを置き換える場合でも、チーム内で独自のフレームワークを分離する必要がある場合でも、以下の 3 つの観点から総合的に検討する必要があります

• チーム

• プロジェクト

• フレームワーク自体

チームメンバーの状況と今後のチームメンバーの状況と地元の雇用市場の状況

現在および将来的にチームにあなたが 1 人しかいない場合 (自分のおもちゃプロジェクトなど)、最も使いたいものを選択してください。しかし、そうでない限り、市場にあるさまざまな一般的なフレームワークを理解し、個人的な好みのことは忘れたほうがよいでしょう。

チームメンバーの現在の状況を理解し、チームの将来の開発スピード、チームに参加する可能性のあるチームメンバーの状況を考慮します。将来のこと、あなたの地域の雇用市場の状況。たとえば、多くの場合、Laravel が適切な選択となりますが、産業が発展していない小さな都市に住んでいて、チームが急速に成長し、多数の人材を採用する必要がある場合、Laravel を選択すると、すぐに「作曲家と最新の PHP スキル」を身につけられる可能性があります。 「トレーニング クラス」のジレンマやその他の「現実的な」フレームワークにより、チームは急速に拡大し、ビジネス開発のニーズに迅速に対応できます

プロジェクトのライフ サイクルと将来の進化の方向

一部のプロジェクトは、会社の主要なビジネスとして、長期的なメンテナンスと継続的な反復を必要とします。他のプロジェクトはサイドプロジェクトや過渡的なプロジェクトである可能性があり、完了後にその後のニーズがない可能性があります。最後に、納品後は需要が無く、別のプロジェクトとして利用できるアウトソーシング/準アウトソーシングプロジェクトもあります。

プロジェクトがどんなに大きくても、要求が多くても、将来の進化を考慮する必要のない 3 番目のタイプであれば、フレームワークの拡張性を犠牲にすることができます (その代わり)たとえば、開発速度やその他の利点を考慮して、完成品の二次開発のためのいくつかのオプションを検討できます。プロジェクトがどれほど小さくても、それが会社の主要なビジネスであり、継続的に反復されるものであれば、ワークロードがどれほど小さくても、フレームワークの拡張性を慎重に考慮する必要があります。

それでは、フレームワークの拡張性とは何でしょうか? CI は非常にスケーラブルなフレームワークですか? ZendFramework1/2 は非常にスケーラブルなフレームワークですか?

答えは、将来の進化の方向次第です。一部のプロジェクトでは、大規模なアクセス トラフィック、一部のプロジェクトでは大量のデータと頻繁な取得による将来のプレッシャー、一部のプロジェクトでは、要件の迅速な反復、頻繁な変更、短いサイクルによるプレッシャーが存在します。プロジェクトが直面する問題がより一般的であればあるほど、さまざまなソリューションを事前に設定したフレームワークが多ければ多いほど、車輪の再発明の必要性を減らすことができる可能性があります。逆に、プロジェクトが直面する問題がより極端であれば、軽量のフレームワークがより適している可能性があります。チームが独自に検討して解決できるように、計画はフレームワークに組み込まれます。さらに、プロジェクトのメンテナンス時間が長くなるほど、変更の予測が難しくなり、さまざまな解決策が事前に設定されたフレームワークを採用するリスクが大きくなります (事前に設定された解決策が各問題を正確に解決できる確率はますます小さくなります) ) )

フレームワーク自体の基本的な品質

パフォーマンスと実行スコア。 C で実装された 2 つのフレームワーク (palcon と Yaf) を除いて、他のフレームワークも同様に高速であると考えてください。さらに、Sina Weibo の PHP フレームワークの置き換えのようなものをホストしている場合、または 100 を超えるプロジェクト Web マシンを管理している場合を除き、PHP フレームワーク

psr とコンポーザーの親和性のパフォーマンス要因を無視してください。これは両刃の剣です。この特性をどう見るかについてはすでに説明しました。

セキュリティ。一部のフレームワークには、独自のセキュリティ脆弱性さえあります。さらに、フレームワーク レベルでセキュリティに関する機能が提供されている場合は、単にコードを読むことをお勧めします。場合によっては、コードを自分で記述するよりも効果的ではない場合があります。

機能。それは、前述したように、プリセットソリューションの量と質です。

モジュール性の度合い。フレームワーク内の各部分がカスタマイズ可能かどうか、およびカスタマイズのコストはどれくらいかかるか。もう 1 つの角度は、フレームの一部がフレームの外で動作できるかどうかです。

表現力（ビジネス機能を実装するためにどれだけのコードが必要か）、この 3 つの特性（表現力、機能性、モジュール性）は互いに矛盾しており、3 つすべての最善を実現することは不可能です。豊富な機能と高度なモジュール性を備え、自由にカスタマイズしたり置き換えたりできるフレームワークでは、多くの場合、通常のビジネス コードを大量に記述する必要があります。 1 つの文で多くの関数を記述することができるフレームワークは、モジュール化されていないことが多く、カスタマイズが困難です。 高度なモジュール性と非構造化ビジネス コードを備えたフレームワークには、多くの場合、豊富なプリセット機能がありません。

周囲の生態、活動レベル、相性。アクティブなフレームワークには成長と改善の余地がありますが、アクティブすぎるとアプリケーションに互換性がなくなる場合があります。もう 1 つの指標は、周囲のエコロジー、誰かがこのフレームワークに基づいて周辺モジュール/プラグインを開発しているかどうか、ドキュメントの充実度、問題発生後の解決策の見つけやすさなどです。

「勝つ方法は常にある」

-- 今後 10 年間、私の頭の中にある Composer と psr-7 と PHP フレームワークについて語る

(この内容はこのセクションは単なる私の個人的な判断であり、中国の国情に基づいて、外国人が最初にこの将来を享受する可能性があります)

PHP は比較的古い言語であり、PHP フレームワークもかなり古い概念です。隣の NodeJS コミュニティは、本当の「Web フレームワーク」がどのようなものであるかを私たちに示す良い仕事をしてくれたと思います。依存関係ソリューションのnpmをコアとし、connect toexpressに代表されるミドルウェアアーキテクチャをスケルトンとして、無数のミドルウェアに囲まれています。ミドルウェア アーキテクチャは Web リクエストとレスポンスの標準インターフェイスを設定し、周囲の他のプロジェクトはこれらのインターフェイスに基づいてさまざまな機能を開発します。エンジニアがしなければならないのは、適切なミドルウェアを見つけてプロジェクトに挿入するか、自分の状況に適したミドルウェアを作成することです (もちろん、オープンソースにしてコミュニティに恩返しするのが最善です)。したがって、「PHP フレームワーク」の概念に相当するプロジェクトは基本的に実行不可能であることがわかります (sails がすでに最高ですか?)

これは、将来の PHP フレームワークについての私の判断でもあります。大規模で包括的な「PHP フレームワーク」の時代は終わりました。 Composer を使用しないフレームワーク、または Composer を使用するふりをするフレームワークには未来はありません。コンポーザーベース、モジュラー、コンポーネントベースのプロジェクトは、強力な入出力標準の統合により、将来的に驚くべき生産性を発揮するでしょう。 symfony/http-foundation は本来良い選択であり、コミュニティも対応するミドルウェアの取り組みを行っています。しかし現時点では、長い間構想されてきた PSR-7 が将来的に勝者になる可能性が高いと思われます。強力な標準と解体されたミドルウェア エコシステムがあって初めて、コミュニティが完全な競争を実現し、開発者が十分な選択肢を得ることができます。A2 フレームワークにはひどいビュー レイヤがありますが、B2 フレームワークにはルーティングは簡単ですが、ビューは貧弱です。次世代の A3 と B3 は両方とも PSR-7 をサポートしています。家に持ち帰って自分で接続するだけです。

広告時間: この判断に基づいて、connect の PHP 移植にはスターが少ないため、独自のミドルウェア アーキテクチャ mcfog/nimo の開発に時間を費やしました。

元のアドレス: http://inside.mcfog.wang/2015/09/ichizon-d/