プログラムを設計するとき、詳細なアーキテクチャ設計を書くべきですか、それとも単に概要を書くべきですか？

タスクのデザインをしているとき、私はこのしつこい気持ちと戦い続けます。それは、一般的なアウトラインであるだけでなく、結局は無視されるというものです。例を挙げましょう。

読み取り/書き込み操作が可能なデバイスのフロントエンドを作成していました。クラス図では、読み取りおよび書き込み機能を提供することは完全に理にかなっています。しかし、実際にそれらを書くことになったとき、コードが1行だけ変更された（読み取りと書き込みの関数呼び出し）文字通り同じ関数であることに気づきました。コードの重複を避けるために、区別するパラメーターを持つdo_io関数を実装しました。オペレーション。さようならオリジナルデザイン。

これはひどく破壊的な変更ではありませんが、頻繁に発生し、プログラムのより重要な部分でも発生する可能性があるため、少なくとも概要の場合よりも、一般的な概要よりも詳細に設計する必要があるかどうか疑問に思わずにはいられません。プログラムのアーキテクチャーになります（明らかに、APIを指定するときは、すべてを詳しく説明する必要があります）。

これは設計の経験不足のせいかもしれませんが、一方で「はるか先の計画をあきらめて、とにかく数日ですべてが変わる」というようなアジャイルな方法論があります。私がどう感じるか。

それでは、設計をどの程度正確に「使用」する必要がありますか

読み取りおよび書き込み操作を提供することが完全に理にかなっている場合、なぜそれらを削除するのですか？

ユーザーの観点からは、それはまだ完全に理にかなっています。実装の詳細は、提供されたインターフェースに干渉してはなりません。

できることは、読み取りと書き込みによって呼び出される内部do_ioを作成することです。

最後に、設計プロセスは次の手順に従います。

• インターフェースを定義する
• 大まかなデザインを描く
• 合意されたインターフェースを変更せずに改良する

プログラムのアーキテクチャ設計は、時間とともに進化します。最初は、正しい設計を行うために必要なすべての情報があるとは思いません。

したがって、最初に考えたデザインに固執すると、おそらく自分を制限することになります。

パブリックAPIを作成しているのでない限り、途中でデザインを変更しても問題ないと思います。

また、最良の方法の1つは、コードからデザインを抽出できるツールに投資することです（NDepend for C＃など）。

アジャイルはこの問題にある程度の成功を収めて答えたと主張しているが、フレッド・ブルックスは40年前に「とにかく捨てるために書いてください。歴史を勉強しない人はそれを繰り返す運命にあります。

したがって、何をすべきかは、設計を計画として扱い、それを変更することのみを目的としています。変更できないデザインは運命です。悪いものを捨てる覚悟が必要です。

設計がパブリックAPI、インターフェースなどの1つである場合、変更のコストが高いため、多くの注意を払う必要がありますが、変更できないため、設計は失敗に終わります。

1秒間はあなたが十分だと思ってはいけません。最初、2回、または3回目でも正しく理解するのに十分な知識があります。

物事が変化するのは、ほとんどの現実のプロジェクトにおける現実です。

• （ご指摘のとおり）プログラムが使用する環境/プラットフォーム/ APIは、当初想定されたものと異なる場合があります
• 要件はいつでも変更される可能性があります
• 市場/周囲の世界が変化し、一部の要件（またはプロジェクト全体）が廃止される可能性があります
• ...

アジャイルメソッドがBig Design Up Frontに対抗するのはこのためです。なぜなら、それは誤ったセキュリティ感覚を与えるだけであり、多くの無駄な努力を伴い、不可避の変更への適応をより困難にするからです。

ただし、アジャイルは「はるか先の計画をあきらめる」ことにはなりません。アジャイル手法には、慎重かつ思慮深い計画の必要な量が含まれますが、それ以上は必要ありません。それらは非常に規律があり、「カウボーイコーディング」とは異なります。適切な量​​の設計を行うことは、過剰設計と過小設計の間の適切なバランスを見つけるための継続的な試みです。しかし、私見では、少なすぎるよりは、多すぎる側を少し誤ることが望ましいです。

最初の設計ではすべてをカバーしようとするべきではありませんが、実装を進める方法を知っていること、アーキテクチャに関する基本的な質問に答えていること、既知の使用方法のメンタルモデルがあることを確信できるはずです。ケースは実際に機能するでしょう。アジャイルビューでは、設計の実際のテストは実装であるため、設計段階でもコードを書き始めたり、想定された設計がどのように見えるかを感じたり、いくつかの仮定をすばやくプロトタイプ化/検証したりできます。 。ただし、これらの初期の作業のほとんどは、与えられた質問への回答が決定したら破棄されます。初期のプロトタイプから実際の製品アプリの構築を開始することは、ほとんど常に悪いことです。

また、実装中に新しい重要な実現を行う場合は、戻って設計を変更することもできます。これは2つのレベルでの重要なフィードバックです。

• あなたの具体的なデザインは、変化する世界に適応する必要があり、そして
• 将来的にこのような可能性をカバーするように設計プロセスを適合させる必要があります（つまり、次回は、デバイスからの読み取りとデバイスへの書き込みのユースケースを事前によく検討します）。

ドキュメントを作成するときは、その目的を理解することが常に重要です。

「アーキテクチャ」ドキュメントと呼ばれるものには注意が必要だと思います。それはすべてスコープの問題です。

複数のチームまたはチームのグループを必要とするシステムについて話している場合は、少なくとも詳細を説明することを目的とするドキュメントについて話していることになります。

• システムのコンポーネントは何ですか
• コンポーネントはどのように接続されていますか
• 各コンポーネントの責任は何ですか
• 誰が各コンポーネントに取り組むべきか

ドキュメントが小規模なシステム用である場合は、既存のシステムに固有の前提条件があるため、含める必要があるアイテムの数を減らすことができます。たとえば、Webサイトでの作業とAPIでのいくつかの新しい呼び出しを行う必要がある機能をまとめるとすると、ドキュメントは次のものを特定する方法として機能します。

• ウェブサイトにどのようなロジックが存在するか
• APIに含まれるロジック
• APIコールコントラクトはどうなりますか（推測）

これらの概要文書は、誰が何をすべきか、どのように統合すべきかについての会話を前面に出すのに役立ちます。これらの決定が行われると、統合の問題が発生する可能性がはるかに低くなるため、チームは主に自律的に動作できます。

知覚する統合の問題が多いほど、ドキュメントをより詳細にする必要があります。

あなたはソフトウェア開発における一般的な難問に出くわしたようです。まだ知らないことが多すぎるため、システムの構築を始める前にシステム全体を計画することはできません。

アジャイル手法が反復的な開発を使用するのはこのためです。これにより、定期的にフィードバックしてソフトウェアの方向を変えることができるため、実際に必要なものから遠ざけることができません。変更するたびにデザインが影響を受けます。

以上のことをすべて説明したので、実際には上記の特定のシナリオ用に2つのメソッドを記述しましたが、2つのメソッドで使用できる3番目のプライベートメソッドに共有ロジックをカプセル化しました。この方法では、公共の方法はただ一つのことに責任があると名前が容易で、read_fileかつwrite_file一方で、彼らは正確に何を言うdo_fileあいまいです。

などブックスクリーンコード、ロバート・C・マーティンと創発デザイン、スコット・Lベインは、この主題にあなたのより詳細な洞察を与えるだろう。

これは設計の経験不足のせいかもしれませんが、一方で「はるか先の計画をあきらめて、とにかく数日ですべてが変わる」というようなアジャイルな方法論があります。私がどう感じるか。

すべての詳細を事前に計画することはできません。あちこちで変更を加えることは完全に許容されます。

ただし、事前に計画することが重要です。アジャイルを行うということは、デザインも計画もまったく意味がないわけではありませんが、変更を期待しているということです。

それでは、設計をどの程度正確に「使用」する必要がありますか

そのままお使いください。石に書かれていないので簡単に交換できます。

アーキテクチャに費やす時間は、システムのその部分のリスクの程度によって決まります。

一般に、アーキテクチャスタイル（レイヤード、コンポーネント、pub-subなど）のかなり早い段階で決定を下す必要があります。クリーンなコードや疎結合がなくても、後からスタイルを簡単に切り替えることができます。プロジェクト。

そうすることで、システム内のさまざまなビルディングブロックの基本的なアイデアが得られ、システムと要件が時間の経過とともに進化するときにロードマップがどうなるかがわかります。

ユースケースに入ると、問題とソリューションを完全に理解できるように十分な設計を行う必要があると思います。何度も何度も行ったボイラープレートコードの場合、それを誤るリスク（アーキテクチャの意味で-もちろんテストする必要があります）は非常に低く、事前設計の量はおそらくかなり最小限に。それが新しい問題である場合、またはソリューションが不明確な場合、またはビジネスにとって潜在的にリスクのある問題である場合は、物事をじっくり考えてみる価値があります。

もちろん、UML、プロトタイプ、ホワイトボードスケッチなど、これを行うにはさまざまな方法があります。どの方法を使用する場合でも、重要なことは、それらの目的は、設計についての考えやコミュニケーションを支援することであるということです。