通常のインターネットプレイに従って、製品マネージャのプロトタイプは、要件のレビューのために良い描画、レビュー後、あなたは、技術マネージャ、または技術の担当者に要件を投げる必要があり、アウトライン設計の完全なセット、およびアウトライン設計のレビューのために、開発のためのアウトラインレビュー。今回は、概要設計の構造についてお話ししましょう。一式を理解しましょう。
ソフトウェアシステム設計
多くの人の目にソフトウェアシステム設計は、ドキュメントを書くことであり、ドキュメントを書くことは負担であり、実際には、システム設計のブレーンストーミングは、非常に幸せなことです。だから、システムの設計とは何かを習得する必要があります。その方法論は何ですか、どのようにいくつかのシステム設計を行うには。
普段は開発や設計をされているのですか？
- このキーボードを持って、まっすぐやってください。
- コーディング開始時の複数の関係者への配慮。
- 要求の中にあるのは、墨を塗るのではなく、とにかくやれ、という言葉です。
- デザインをするとき、開発者は考えていますか？それともテクニカル・マネージャーが考えているのでしょうか？
どんな方法で？
ウォーターフォールプロセス
要件は、システム設計のすべての側面の包括的な設計に基づいて識別され、方法の大規模なソフトウェアの開発の主流の検証の非常に厳しい条件の各段階を置きます。
プロトタイプに基づく迅速な反復
多くのスタートアップのオーナーは、ウォーターフォールが純粋に好きで、ビジネスが素早く開発できると感じていますが、実際にはそこにはまだ多くの穴があります。ウォーターフォールに基づいて開発する人はほとんどいません。実際、迅速な反復は、多くの上司が古い鉄がプロジェクトを急がせる理由となっています。私は、単一の数億は、まずユーザーの検証を聞かせて、ユーザーエクスペリエンスは、我々は偉大なビジネスモデルを遅らせることはできませんので、この開発モデルはまた、ドキュメントを持っている必要がある場合でも、設計は、多くの場所、後期および拡張のパフォーマンスを含め、その中に多くの穴があることが明確でないか、初期の段階の底が良いを構築しなかった場合、後期の怪我。さりげなく小さな機能を変更すると、骨を傷つけるためにプログラムにする必要があるかもしれません。しかし、今回は上司があなたを気にしない、テスターがあなたを気にしない、製品があなたを気にしない、彼らは唯一のビジネスと需要を満たすために知っています。
デザインとは
具体的に何を設計する必要がありますか？システムが設計の良い仕事をしていない場合、あなたはまだ、いわゆるプロトタイプに基づいている場合は、言い訳として、これに迅速な反復アジャイル開発は、プログラムが後でますます大きく、より多くの大きな時間が純粋に傷ついた場合、単にあなたのシステムを変更しないでください、例えば：銀行、社会保障コード内部基本的に10年前、コードの内部には、問題の全体の多くがありますが、誰も合理的な設計の部門は、につながる変更する勇気はありません。欠陥。
- アーキテクチャ設計 1. システムとは何かを特定するもので、ソフトウェア全体の最も重要な表現です。
開発者がドキュメントを見るとき、最初に見るのはアーキテクチャです。これはソフトウェアシステムの最も本質的なもので、本体の形、人間の骨格がアーキテクチャです。もしアーキテクチャをゴリラにしてしまうと、その後どのように進化しようとも、どのように発展しようとも、人間になることはできません。例えば、家を建てるにしても、高層ビルを建てるかもしれないし、土の家を建てるかもしれないし、バンガローを建てるかもしれないし、窯を建てるかもしれないし、最初から高層ビルを建てようと思えば、材料や基礎の深さなどが違ってきます。ですから、建築にはソフトウェア設計の本質を理解する必要があります。建築といってもいいでしょう。
2.安定した設計
建築の途中で基礎を変更しなければならないのは悲しいことです。デベロッパーは、設計についてよく考えなければなりません。
3.デザインの原則
3.1 適応
ビジネスの目的を達成するために、ユーザーのニーズを満たしています。代わりに、開発者自身の曲がった、高レベルの設計者は、ソフトウェアのユーザーのニーズを満たすために設計することではなく、すべてのコストでコード設計のうち、最先端のソフトウェアは、ない最高の、唯一の最も適切です。クローズドループを作成するには、多くのインターネットプロジェクトのための最高の、需要需要だけでないかもしれないが、成熟したビジネスモデルではないかもしれない、あなたがクローズドループを実施する必要がある場合は、試行錯誤の機会が与えられていない、上司のコストの開発を受け入れることができない、上司はすぐに内部の市場に昇格することはできません。より多くの機能が開発され、より強力な機能は、一度ビジネスの調整は、ソフトウェアを変更するには良いことではありません。だから、多くの段階に分割する必要があります。開発とプロダクトマネージャーは、この問題になりやすい、設計の始まりは、大規模かつ包括的な、細かいと詳細のようなものです。 プロダクトマネージャーはよく言います："他の人のシステムはこの機能を持っている、なぜあなたはそれを行うことができません！実際には、過去を嫌うことができる、彼に教訓を与える："この製品の設計は、単に製品設計の適応性の現在の段階を満たすことができません！
3.2 構造的安定性
家の基礎とは対照的に、頻繁に変更する場合は、比較的安定していることを確認する必要があり、比較的安定しているように設計され、あなたはその家が頻繁に変更された基礎の後に建て参照してください。ソフトウェアが頻繁に発生した場合、あまりにも悲劇的な。アーキテクチャの設計が安定していない、スコープが明確ではない、システムがちょうどB2Cに始まっている場合、突然B2B、テーブル構造、システムモジュール、インターフェイスになりたい、すべての比較的大規模な変更する必要があります。プロジェクト全体が非常に混沌とし、ノンストップの変更の要求は非常に混沌としたシステムにつながります。結果は、開発者がコードを移動する勇気がない、コードのコピーをコピーしているということです。最終的には、コードの複数のコピーを維持します。高レベルの設計者は一定の経験を持っているため、それらの要件は基本的に変更されていないことを事前に知ることができ、それらの要件は可変です。可変要件と可変要件を導き出すことが重要です。例えば、メッセージセンター、メッセージセンターの設計プロジェクトです。PCメッセージだけでなく、携帯メッセージ、物流メッセージ、マーケティングメッセージ、通知メッセージもたくさんあります。当時、問題があって、実際のメッセージセンターは、メッセージの様々なチャンネルを受信し、その後、様々なプラットフォームに配布することです。メッセージセンターは存在せず、すべてビジネスサイド自身が行います。アトム性を満たすために、アトムは不変であり、メッセージセンターがすべきことは、ビジネスサイドの要求に従って、対応するチャネルであるSMSにメッセージを送り出すことです。しかし、メッセージ・センターはビジネス・プラットフォームの後に設計され、ビジネス・プラットフォームはメッセージを送信するために自身のビジネス・コードを変更することができません。メッセージ・センターでは、ビジネス・サイドのアクションをリスニングするためのリスニング・モジュールが特別に設計されています。 このモジュールはビジネス・プラットフォームと緊密に結合しており、イベント・リスニング・モジュールはビジネスに合わせて変更されますが、メッセージ・センターのコア機能は変更されません。これが、その時の安定性を確保する方法です。モジュールは分割されています。後で分割する必要があれば、モジュールを直接分割することができます。モジュールを聞いて、ビジネスの変化に応じて変更してください。安定性は、あなたがビジネスの需要側に駆動されることはありません、プロジェクトは制御可能です。日々、上司を心配する必要がなく、新しい要求があります。
3.3 拡張性
新しい機能でソフトウェアを拡張するのがどれだけ簡単か。スケーラビリティが高ければ高いほど、変化に対応する能力が高くなります。特にアジャイル開発では、スケーラビリティが高くないと行き詰まりやすくなります。変更可能なものと変更不可能なものの区別。ソフトウェアのボリュームが小さければ小さいほど、スケーラビリティは高くなり、小舟に乗れば乗るほど、スケーラビリティは高くなります。プロジェクトをフェーズに分けるのは、拡張性のため。システムのボリュームは確かにビジネスによって制限され、大規模なプロジェクトのスケーラビリティがより困難であるため、分散されるように、層状に、より安定したダウン。ビジネスモジュールの合理的な分割は、拡張を分割するモジュールに応じて時間の拡張。ビジネスの境界分割。
3.4 すべてのシステムは拡張性を考慮して設計されていますか？
一回限りのプロジェクトであれば、現段階の機能が完成していれば、例えば、2つの別会社のドッキングインターフェイスなど、実際には、何度も一回限りかもしれないので、スケーラビリティを考慮する必要はありませんが、もし考慮すれば、過剰設計になるかもしれません。あなたがオープンプラットフォームをやっている場合は、間違いなくスケーラビリティを考慮する必要があります。
3.5 再利用性
ツール、パブリック・コンポーネント。ツールは純粋に
- テーブル構造設計
- 方法論
- テーブル構造設計
- パフォーマンスのスケーラビリティに関する考慮事項
システムのモジュール設計
プロトタイプのインターフェースデザイン
デザインパターン
データ構造とアルゴリズム
追記：設計をしないこともありますが、設計をした後では、設計をしないのとは明らかに大きな違いがあります。事前に良いデザインをたくさんしておけば、デザインはとても簡単でコントロールしやすくなります。人がデザインについてどれだけの理論を持っているかに関係なく、デザインは必須です。事前設計のすべてが事前設計ではありません。デザインは開発者、テスター、プロダクトマネージャーのためのものです。
