Web 開発の第一人者のほとんどにとって、私の質問はばかげているように聞こえるかもしれませんが、初心者として、フロントエンドを開発し、バックエンドの後でのみ開発してもよろしいですか?
また、データベースが必要な場合は、最初に設計する必要がありますか?
プロジェクトの分析部分についても知りたいです。要するに、友人は、プロジェクトの要件分析 (内部、技術、および設計) を開始する必要があることを教えてくれました。たとえば、ユーザーが登録できるソーシャル e コマース サイトを構築したいとします。そのようなプロジェクトの分析を準備するために何をするか、番号付きのリストを決定できますか (1. データベース設計 a) データ モデルの準備...)
誰かが完全な答えを提供できれば、とてもうれしいです。
ありがとうございました。
よろしく、 ドニー
私は通常、最初にフロントエンドで必要なフィールドを決定します。
次に、データベース バックエンドの作業を開始します。次に、ユニット テストを含む中間層、最後にフロント エンドです。
もちろん、フロントエンドの作業を開始すると、さらに多くのフィールドやデータベースの変更を考えます....それが開発の性質です。
この質問は、ボトムアップ設計とトップダウン設計のどちらが優れているかという質問のバリエーションだと思います。フロント エンドの大まかなドラフトを作成して、サイトの一般的な使用法をシミュレートすると役立つことがわかりました。これは、他の方法では見逃していた必要なバックエンド オプション (必要なデータを考える) を確認するのに役立ちます。
特に新しい人がプロジェクトに取り組んでいるときは、漸進的なアプローチをお勧めします。
必要になるとわかっている機能をいくつか選択します。データベース (SQL)、バックエンド コード (PHP など)、Web フロントエンド (HTML) から始めます。その 1 つの機能ブロックを実現するために、できるだけシンプルにします。物事の順序は、一度に作業するために小さなチャンクを取得するほど重要ではありません.
その小さな部分が機能したら、コピーを保存します。バージョン管理も。そうすれば、明日何かを台無しにしても、いつでも機能していたものに戻ることができます.
次に、次の小さな機能を選択して追加します。私はいつもこれが非常にやる気を起こさせます。一貫した改善が見られます。
HTML への変更は実際には HTML にしか影響を与えませんが、データベースの変更にはしばしば HTML の変更を必要とするバックエンド コードの変更が必要であり、すべてをやり直さなければならないのは苦痛です。
システム全体に存在すると予想される層を設計する必要があります。各層は、さまざまな人が並行して設計/実装できますが、統合ポイントでは、契約を決定するためにコラボレーションが必要になります。
2つの一般的なインターフェース/コントラクトパターンがあります。
1）コンシューマー/アプリケーションのニーズ->インターフェイス/コントラクトはアプリケーションによって決定され、次の層はそれらのニーズに準拠/適応するように作成されます。現在、すべての層は基本的に下流の消費者によって推進されています。長所は、必要な方法のセットが最も効率的で限られている可能性が高いことです。短所は、システムを他の消費者に適応させるための作業が増えることです。
また
2）サービスプロバイダー->インターフェイス/コントラクトは、多くのアプリにサービスを提供する可能性のある共通機能のコアセットをサポートするように設計されたサービスによって決定されます。次に、プロバイダーを使用するアプリケーションは、コントラクトの機能を内部のニーズに適合させる必要があります。長所は、サービスを変更せずに再利用できることですが、これらの一般化された方法は、特定のアプリのニーズにあまり効率的に適合しない可能性があります。
これらはどちらも完璧な答えではなく、状況によって異なります。上記の1または2の決定は、作業している層接続によっても異なる場合があります。サービスコントラクト＃2のサービス、独自のニーズコントラクト＃1のアプリ、そしてアプリのニーズをサービスの機能にマップするアダプター層を作成できます。
使用するパターンに関係なく、特定の層で作業を開始するときよりも、層のアーキテクチャ、それらのコントラクト、およびそれらが互いにどのように相互作用するかが重要です。
一般に、層の設計が整ったら、契約が定義されている層で作業し、契約が消費されている層でフォローアップします。