開発者の啓示
フレームワークでWebサイトを開発する過程で、MVCを常に扱っています。 また、新しいプロジェクトを開始するたびに、開発者は以前のプロジェクトよりも改善し、蓄積したすべての開発経験を新しいリリースに適用したいと考えています。 開発者は、ファッションに最も一貫性のある他のフレームワークをマスターしようとすることがあります。 それどころか、より保守的な見方を堅持して、彼らは使い慣れたフレームワークを「使用」しようとします。 いずれにしても、開発者は独自のライブラリ、モジュールを作成するか、既製のソリューションを実装する必要があります。 結論はすぐに「フレームワークを追いかける特別な理由はありません」と懇願します。
すべての適切な開発者は、彼のプロジェクトが死なず、「名前のない」ホスティング上のクラウドのRAIDアレイで埃っぽくならないことを深く望んでいます。 しかし、原則として、開発者自身は将来、完成したプロジェクトのサポートに関与することを望みません。特に、彼の潜在能力が新しい興味深いプロジェクトの開発に向けられている場合はなおさらです。 しかし、プロジェクトの運用後にプロジェクトをサポートおよび開発することが主なタスクである開発者の別のカテゴリがあり、これらの専門家はプロジェクトが運用される前に開発プロセスに常に直接関与していませんでした。 したがって、最後の結論を続けます。「...、開発者の高度なコミュニティまたはZendなどの「豊かな父親」と一緒に、よく文書化された人気のあるフレームワークを選ぶだけで十分です。」
ただし、さまざまなライブラリとテクノロジーを適切に使用する必要があることを忘れないでください。 しかし、最も重要なことは、開発への適切なアプローチを選択することです。 現在、おそらく、どの開発者も、最新のWebプロジェクトで「開発イメージ」を使用する必要性全体を理解しています。 おそらく、誰かが意見を異にし、「デザインパターン」やOOPの使用もパフォーマンスの点で冗長すぎて、プロセッサリソースとメモリリソースが最適に使用されておらず、特にWebにとって「クール」すぎると主張するでしょう。その後、コードはインタープリターによって処理されるため、コードのデバッグプロセスが複雑になります。 ある程度、これはすべてそうです。 しかし、実際に示されているように、プロセッサリソースの不足の問題は、たとえばFacebookなどの膨大なトラフィックを伴う大規模なWebプロジェクトに関しては、通常最後の場所にあります。 言うまでもなく「高負荷」の条件下では、World Wide Webのユーザーから継続的に受信されるデータベースクエリの「ストーム」のおかげで、主な問題は1秒間にハードドライブのスピンドルモーターの回転数に減少します。 ご存知のように、負荷の高いプロジェクトでは、プロジェクトデータベースを1つ以上のデータセンターの複数のクラスターに水平スケーリングする必要があります。 RAMのリソースは、データをキャッシュするためにほぼ完全に消費されます。 結論は次のとおりです。「Webプロジェクトの開発の柔軟性と、デザインパターンの使用によって保証されるさらなるサポートを節約すべきではありません。」
Webプロジェクトのオブジェクトモデルを作成するときに使用しないことをお勧めします。多重継承を避けます。これはクールとはほど遠いもので、まったく柔軟性がありません。
多重継承の欠点：
すべての適切な開発者は、彼のプロジェクトが死なず、「名前のない」ホスティング上のクラウドのRAIDアレイで埃っぽくならないことを深く望んでいます。 しかし、原則として、開発者自身は将来、完成したプロジェクトのサポートに関与することを望みません。特に、彼の潜在能力が新しい興味深いプロジェクトの開発に向けられている場合はなおさらです。 しかし、プロジェクトの運用後にプロジェクトをサポートおよび開発することが主なタスクである開発者の別のカテゴリがあり、これらの専門家はプロジェクトが運用される前に開発プロセスに常に直接関与していませんでした。 したがって、最後の結論を続けます。「...、開発者の高度なコミュニティまたはZendなどの「豊かな父親」と一緒に、よく文書化された人気のあるフレームワークを選ぶだけで十分です。」
ただし、さまざまなライブラリとテクノロジーを適切に使用する必要があることを忘れないでください。 しかし、最も重要なことは、開発への適切なアプローチを選択することです。 現在、おそらく、どの開発者も、最新のWebプロジェクトで「開発イメージ」を使用する必要性全体を理解しています。 おそらく、誰かが意見を異にし、「デザインパターン」やOOPの使用もパフォーマンスの点で冗長すぎて、プロセッサリソースとメモリリソースが最適に使用されておらず、特にWebにとって「クール」すぎると主張するでしょう。その後、コードはインタープリターによって処理されるため、コードのデバッグプロセスが複雑になります。 ある程度、これはすべてそうです。 しかし、実際に示されているように、プロセッサリソースの不足の問題は、たとえばFacebookなどの膨大なトラフィックを伴う大規模なWebプロジェクトに関しては、通常最後の場所にあります。 言うまでもなく「高負荷」の条件下では、World Wide Webのユーザーから継続的に受信されるデータベースクエリの「ストーム」のおかげで、主な問題は1秒間にハードドライブのスピンドルモーターの回転数に減少します。 ご存知のように、負荷の高いプロジェクトでは、プロジェクトデータベースを1つ以上のデータセンターの複数のクラスターに水平スケーリングする必要があります。 RAMのリソースは、データをキャッシュするためにほぼ完全に消費されます。 結論は次のとおりです。「Webプロジェクトの開発の柔軟性と、デザインパターンの使用によって保証されるさらなるサポートを節約すべきではありません。」
Webプロジェクトのオブジェクトモデルを作成するときに使用しないことをお勧めします。多重継承を避けます。これはクールとはほど遠いもので、まったく柔軟性がありません。
多重継承の欠点：
- 異なるタイプ（クラス）のデータ構造の要素（プロパティ、メソッド）を横断するときに正しい結果が得られるという100％の保証はありません。開発者は常にこれらのクラスを覚えておく必要があります。
- 一般に（複数ではなく）継承を悪用すると、独自の祖先の多くのメソッドとプロパティを組み合わせたかさばるクラスが得られます。そのいくつかのメソッドとプロパティは、おそらく子孫クラスでは必要ありません。 そのようなクラスのオブジェクトは非常に冗長になる可能性があります。
- クラスを維持する柔軟性が失われます。先祖クラスの1つを変更する必要がある場合、すべてまたは一部の子孫を変更する必要があります。
- 機能が似ているがすべての祖先クラスの異なるセットを必要とするオブジェクトのセットを作成する必要が生じた場合、またはそのようなオブジェクトの祖先クラスを継承するシーケンスが異なる場合、この場合、異なる各オブジェクトのクラスを作成する必要があります祖先の継承のシーケンスまたはその構成によってのみ、他から。
All Articles