私は、大規模な新しいシステムの背後にある唯一の開発者になると言われています。特に、UIとデータベーススキーマを設計します。
きっと指導を受けると思いますが、靴下を脱ぎ捨てられるようにしたいと思います。その間に準備するために何ができますか？また、仕様を使用してコンピューターの前に座るときは、何を覚えておく必要がありますか？
覚えておくべきいくつかのこと：私は私の最初の実際のプログラミングの仕事で大学生です。Javaを使用します。すでに自動テストなどでSCMを設定しているので、ツールは問題ありません。
OOPについてよく知っていますか？もしそうなら、SpringとHibernateを調べて、実装をクリーンで直交させてください。それが得られれば、特に「自動テスト」を実行しているので、TDDは設計をコンパクトで無駄のないものに保つための良い方法であることがわかるはずです。
更新：最初のたくさんの答えを見て、私はこれ以上反対することはできませんでした。特にJavaの分野では、データベース中心のアプローチではなく、オブジェクトを使用してアプリケーションを作成するためのメンター/リソースをたくさん見つける必要があります。データベース設計は通常、Microsoftの人々にとっての最初のステップです（私は毎日行っていますが、回復プログラム、えー、Alt.Netにいます）。顧客に提供する必要があるものに焦点を合わせ続け、ORMにオブジェクトを永続化する方法を理解させる場合、設計はより優れたものになるはずです。
これは私の最初の仕事と非常によく似ています。大学を出てすぐに、データベースとビジネスロジックレイヤーの設計を依頼されましたが、他の人がUIを担当していました。その間、上司は私の肩越しに見つめていました。以前は自分の赤ちゃんであったものを手放すことを望まず、現在は私のものであり、その中に指を突っ込んでいました。3年後、開発者は会社から逃げ出し、私たちはまだ実際に何かを売るのにXか月もかかりませんでした。
大きな間違いは、野心的すぎることでした。これがあなたの最初の仕事であるならば、あなたは間違いを犯し、あなたがそれらを書いた後ずっと物事がどのように機能するかを変える必要があるでしょう。データベースレベルと他の開発者に提示したAPIの両方で、システムを必要以上に複雑にするあらゆる種類の機能がありました。結局、すべてを一度にサポートするには複雑すぎて、ただ死んでしまいました。
だから私のアドバイス：
このような大きな仕事を片手で引き受けることに自信がない場合は、そうしないでください。あなたの雇用主に伝えて、あなたがあなたを助けることができる誰かと一緒に働くために誰かを見つけるか雇うように彼らに頼んでください。人々をプロジェクトに追加する必要がある場合は、問題が発生し始めた後ではなく、開始近くで行う必要があります。
製品の目的を慎重に検討し、考えられる最も単純な一連の要件に要約します。あなたにスペックを与えている人々が技術的でないなら、彼らが書いたものを過去に見て、実際に機能してお金を稼ぐものにしようとします。顧客や営業担当者と話をし、市場を理解します。
あなたが間違っていることを認めるのは恥ずべきことではありません。最初のバージョンでミスをしたためにシステム全体を書き直す必要があることが判明した場合は、できるだけ早くこれを認めて、システムにアクセスできるようにすることをお勧めします。同様に、最初のバージョンで起こりうるすべての偶発事象を予測できるアーキテクチャを作成しようとしないでください。すべての偶発事象が何であるかがわからず、間違ってしまうからです。捨ててやり直すことを念頭に置いて一度書いてください-あなたはそうする必要はないかもしれません、最初のバージョンは問題ないかもしれませんが、そうするならそれを認めてください。
また、データベースから始めることについても同意しません。DB は、ビジネス オブジェクトがどのように永続化されるかの単純な成果物です。Java に相当するものは知りませんが、.Net にはSubSonicなどの優れたツールがあり、ビジネス オブジェクトの設計を繰り返しながら DB 設計を流動的に保つことができます。何よりもまず (導入するテクノロジを決定する前であっても)、プロセスに焦点を合わせ、名詞と動詞を特定し、それらの抽象化から構築することをお勧めします。OOP 101 で教えてもらったように、「現実の世界」で実際に機能します。
コーディングを開始する前に、データベーススキーマを計画してください。他のすべてはそこから流れます。早い段階でデータベースを適切に修正することで、後で時間と頭痛の種を節約できます。
重要なことは、システムの複雑さを抽象化して、始めてすぐに行き詰まらないようにすることです。
まず、仕様をストーリーのように読みます (ざっと目を通します)。その場で分析するためにすべての要件に立ち止まらないでください。これにより、システムの全体像を詳細なしで把握できます。この時点で、システムの主要な機能コンポーネントの特定を開始します。これらを書き始めます (必要に応じてマインドマップ ツールを使用してください)。
次に、各コンポーネントを取り出して分解を開始します (そして、各詳細を仕様書の要件に結び付けます)。すべての要件をカバーするまで、すべてのコンポーネントに対してこれを行います。
ここで、コンポーネント間の関係と、さまざまなコンポーネント間で機能や機能の繰り返しがあるかどうかを確認する必要があります (これらを引き出して、ユーティリティ コンポーネントなどを作成できます)。今頃、あなたの頭の中に要件の詳細な地図ができているでしょう。
ここで、データベース、ER ダイアグラム、クラス設計、DFD、展開などの設計について考える必要があります。
最後のステップを最初に実行することの問題点は、最初から全体的な理解を得ることなく、システムの複雑さに行き詰まる可能性があることです。
私の経験では、データベースを最後に考慮するJavaアプリケーション（.NETも）は、企業環境に配置するとパフォーマンスが低下する可能性が非常に高くなります。あなたは本当にあなたの聴衆について考える必要があります。あなたはそれがウェブアプリであるかどうかを言いませんでした。いずれにせよ、データの処理方法を検討する際には、実装しているインフラストラクチャが重要です。
どのような方法を検討する場合でも、データを取得および保存する方法と、それがパフォーマンスに与える影響は、最優先事項の1つとしてすぐそこにある必要があります。
私はそれを逆にします。データベーススキーマを最初に実行すると、永続性から抽象化するのが難しいデータ駆動型設計でシステムがスタックすることがわかります。最初にドメインモデルの設計を行い、次にそれらに基づいてデータベーススキーマを作成しようとします。
そして、インフラストラクチャの設計があります。チームは、何よりもまず、プログラムを構造化する方法に関する規則を決定する必要があります。次に、私たちは協力して、最初にシステムの共通機能の設計について合意します（たとえば、永続性、ロギングなど、誰もが必要とするもの）。これがシステムのフレームワークになります。
残りの機能を自分たちの間で分割する前に、私たち全員が最初に一緒に取り組んでいます。
このアプリケーションをどのように使用するかを考えることをお勧めします。将来のユーザーはそれをどのように使用しますか? このアプリケーションが何を処理する必要があるかについて、少なくともいくつかのことを知っていると思いますが、私の最初のアドバイスは、「ユーザーと、ユーザーが何を必要としているかを考えること」です。
コードをどこで区切るかを考えながら、普通紙に描きます。ロジックと GUI コードを混在させないでください (一般的なエラー)。このようにして、アプリケーションの範囲を将来サーブレットやアプレット、または登場するあらゆるプラットフォームに拡張することができます。すべてを再構築することなく、大きな変更に迅速に対応できるように、レイヤーに分割します。レイヤーは、最も近い隣接レイヤー以外のレイヤーを認識してはなりません。
真のコア機能から始めます。時間のかかるすべての綿毛 (プロジェクトが 4 週間遅れることになります) は、ほとんどのユーザーにとっては大した問題ではありません。時間通りに配達できることが確認できたら、後で追加できます。
ところで。これはデザインとは関係ありませんが、納期に間に合わないとだけ言いたいです。時間の消費を現実的に見積もってから、それを 2 倍にしてください :-) ここで、このプロジェクトではあなたが 1 人ではなく、プロジェクトの進行に合わせて人々が行き来すると仮定します。プロジェクトの途中で人々を訓練する必要があるかもしれません, 人々は休暇に行きます/手術が必要です.
大きなシステムを小さな部分に分割します。通常はそうではないので、それほど複雑だとは思わないでください。複雑すぎると考えると、思考が台無しになり、最終的にはデザインが台無しになります。同じことがもっと簡単にできることに気づき、それを再設計するという点もあります。
少なくともこれは、設計における私の大きな間違いでした。
単純にする！
に基づいて、新しい大規模なプロジェクトを開始することについて、非常に洞察に満ちたアイデアを見つけました。
テストによって導かれるオブジェクト指向ソフトウェアの成長という本の中で。
まだ開発中ですが、最初の 3 つの章はあなたが探しているものであり、読む価値があるかもしれません。