私はチームメイトと一緒に、XPを自己学習してその原則を適用しようとしています。TDDでの作業に成功し、コードとデザインを楽しくリファクタリングしています。しかし、プロジェクトの設計の全体像。
最近、コードの効果的な継続的設計のための「良い」実践とは何なのかと思っていました。 CRCカードや通信図などの適切なモデルを厳密に探すのではなく、システムの高レベルのビューで常にコラボレーションするための手法を探しています(ではありません)高すぎます)。
私は自分自身をよりよく説明しようと思います。実際には、CRCカードを使用してモデルをブレインストーミングする方法に興味があり、非常に大まかなUMLダイアグラム(既に使用しているもの)とそれらを混合します。ただし、私たちが探しているのは、反復中にモデル化するwhen、howおよびhow muchを決定するためのいくつかの原則です。
この問題について何か提案はありますか?たとえば、チームメイトとあなたが知っている場合、設計セッションと会議の仕組みが必要ですか?
新しい機能やリファクタリングを実装する方法について不安を感じるときはいつでも、設計セッションを呼び出します。または、私たちが(大まかな)アイデアを明確に持っていると感じても、問題全体が完全に監督されないほど問題が複雑です。
最初のケースでは、問題を一緒に議論し、他の人から考え、提案、批判を得ることが有益であることは明らかです。 2番目のケースでは、ラフなデザインをチェックする目が多いほど良いと言えます。しかし、設計が「完全」であることが判明しても(実際には実際に発生することはありません)、チーム内の特定の問題とその解決策についての共通の理解shareは有益です。これにより、チーム全体で一貫したアーキテクチャのビジョンを維持できます。
大まかなUMLスケッチを使用しますが、CRCカードは使用しません。
私の見たところ、複雑なプログラムを構築することは、家を建てるようなものです。どのように家を建てますか?設計図を描いたり、木製フレームを作成したり、配管を設置したり、電気を設置したり、フレームを屋根で覆ったり、床にタイルを張ったりする必要があります。建設する部屋の数がわからない家。別の部屋を追加する必要があるため、壁を壊してしまい、取り壊さなければならない場合があります。さらに悪いことに、それはバスルームになるので、新しい部屋に直接配管するために床を完全に引き裂く必要があるでしょう。
残念ながら、構築する部屋の数がわからないことは、プログラムの設計ではかなり普通のことであり、場合によってはそれが助けにならないことがあります。ただし、このアイデアを念頭に置いて複雑なプログラムを設計するための良いアプローチは、ほとんど変化しないと予想されるすべての方法で制限するスケルトンを構築することです(たとえば、データベースにアクセスするためのインターフェースを作成します。プログラムのある時点でデータベースにアクセスする必要があります)。スケルトンにかなりの労力を費やすと、変更の可能性が予測されるため、将来の変更は簡単になります。後で壁をノックダウンしてメタファーに戻るのではなく、部屋を拡張する可能性があったため、壁を構築することはありません。
すべてのことは言われていますが、すべての変更を予測することは不可能であり、いくつかの変更をコミットせずにプログラムをうまく構築することはできないため、プログラム設計を作成するための最善の方法を知るには経験が必要です。
実行するフローがある特定のシステム用のコードを書いています。なぜ私たち自身がデザインをしているのかを理解することは非常に重要です。設計は私たち自身のためではなく、システムを使用し、システムをプログラムし、システムを保守するユーザーのためのものです。ユーザーの視点でシステムを理解したい場合、その設計はシステムのプログラマー向けに作成された設計とは明らかに異なります。特定のユーザーの要件を満たすツールを適宜選択してください。
私は方法を組み合わせて使用します: