私は最近大学を卒業し、プログラマーとして仕事を始めました。「技術的な」問題を解決したり、1つの解決策があると言うことでデバッグしたりすることはそれほど難しいとは思いません。

しかし、明らかな解決策が1つもない問題のクラスがあるようです-ソフトウェアアーキテクチャのようなもの。これらのことは私を混乱させ、大きな苦痛を引き起こします。

私は自分のプログラムとシステムをどのように「アーキテクト化」するかを決めるのに何時間も費やしています。たとえば、このロジックを1つまたは2つのクラスに分割したり、クラスにどのように名前を付けたり、プライベートまたはパブリックにしたりする必要があるかなどです。プログラムを作成したいだけです。

アーキテクチャフェーズをより迅速に達成し、楽しんでいるコーディングおよびデバッグフェーズに到達するにはどうすればよいですか？

完璧は善の敵です。

とはいえ、角を切ってはいけません。ソフトウェア設計は長期的な影響をもたらし、将来的にあなた（および同僚）の膨大な時間と労力を節約します。正しくなるには時間がかかります。プログラミングに費やされた時間のほとんどはキーボードを叩くのではなく、ホワイトボードが問題を解決する方法を見つけ出します。

しかし、完璧さについても心配するべきではありません。2つのデザインが膠着状態と戦う場合、それはそれらが同じ長所である可能性が高いことを意味します。1つだけで行きます。その設計の欠陥を見つけたら、物事を変えることができないというわけではありません。

（そして、うまくいけば、技術的な問題をデバッグ/解決する方法が1つだけではないことがわかったら、それが助けになることを願っています。）

シンプルで小さなプログラム（たとえば、1万行未満のソースコード）の場合、コードを記述しながらそれらを設計できます。反復的かつ漸進的な開発アプローチを採用する場合、途中でアーキテクチャ上の決定を段階的に行います。数十行のコードを記述し（単一のマイクロ機能を追加）、コンパイラから警告が返されなくなるまでそれらを改善し、デバッガ、そして繰り返します。

このロジックを1つまたは2つのクラスに分割しますか、クラスに名前を付ける方法、プライベートまたはパブリックにする必要がありますか。これらの種類の質問は多くの時間を費やします

彼らはすべきではありません。また、小さなプログラムの場合はそれほど重要ではありません（小さな単純なプログラムの方が、名前の変更などの改善が容易だからです...）。一貫性を保ち、ソースコードの可読性を優先する必要があります。プログラムの小さな部分をわずかにリファクタリングする必要がある場合があります（それは大したことではありません）。

これを多くのフリーソフトウェアプロジェクト（Linuxカーネルのような大きなプロジェクトでも）と比較してください。開発者は、初期段階で「アーキテクト化」に多大な労力を費やしませんでした。UMLはフリーソフトウェアではほとんど使用されません。さらに、いくつかのフリーソフトウェアプロジェクトのソースコードを学習することで、かなり多くを学ぶことができます。

初心者として、チームで大規模なソフトウェアプロジェクトに取り組みます。そこでは、単純に（アーキテクチャの決定を行う）上級開発者を信頼できます。ソースコードの行）。後者の場合、段階的なアーキテクチャの決定を行い、アプリケーションを時々リファクタリングします。その後、「アーキテクチャ設計」は自然に進化します。

アーキテクチャフェーズからコーディングとデバッグのフェーズに、より迅速に到達するにはどうすればよいですか？

1年もかからない小さなソフトウェアプロジェクトの場合、非常に簡単です。アーキテクチャを実行しないでください。おそらく、設計全体について30分ブレインストーミングを行います。次に、反復的かつ漸進的な開発アプローチでコードの記述を開始します。数十行を記述し、警告が表示されなくなるまでコンパイルします（たとえばg++ -Wall -Wextra -g、GCC for C ++ ですべての警告とデバッグ情報を有効にします）。コードアナライザー（clang-analyzerなど）がある場合は、デバッガーでそのコードをテストし、バージョン管理にコミット（例git）、すすぎ、繰り返します。ただし、技術的な負債を避けるようにしてください：何か悪臭がするときは、改善するために（リファクタリングと再実装によって）作業を行います。

一方、チーム環境では、アーキテクチャの作業では、すべてのチームメンバーの責任を定義するための最初の議論が必要です。その議論は、シニア開発者（初心者ではありません）が主導します。アジャイルなソフトウェア開発とThe Mythical Man-Monthについて読んでください。

プログラムを作成したいだけです。アーキテクチャをせき止めます。

優れた直感（少なくとも小規模なプロジェクトの場合）。したがって、プログラムについて数分考え、反復的かつ漸進的な開発アプローチでコーディングを開始します。数十行をコーディングし、正常に動作することを確認してから、繰り返します。その前に、同様のフリーソフトウェアプロジェクトのソースコードを調査し（そしてアーキテクチャを観察し）、より一般的には書誌的作業と研究を行います。

では、いくつかの例、について考えメタプログラミングアプローチ：あなたがしたい状況がある生成いくつかの「ソースファイル」は（例のようなパーサジェネレータ使用することを含んでバイソン、のようなグルーコードジェネレータSWIGは、GoogleのいるProtobufを、そして時にはあなたが書きたいと思うかもしれません単純なスクリプト-またはGPPなどの汎用プリプロセッサを使用して-C ++またはJavaコードの一部を出力して、コーディングの繰り返しを回避します）。

PS。私は研究エンジニアであり、コンピューターサイエンスの博士号と40年の経験があり、いくつかの中規模プロジェクトといくつかの大きなプロジェクト（GCCコンパイラー自体）。私にとって「アーキテクチャ」は、今後数日または数週間の作業の計画段階にすぎません（夢や眠りながら、確かにコンピューターも、通常は鉛筆も使用せずにそれを行います）。また、研究助成金を書くとき、私はなんとかして不完全にアーキテクチャを設計しています。

注意：一部のソフトウェアプロジェクトには、他のプロジェクトよりも多くのアーキテクチャが必要です。たとえば、人工心臓または脳神経外科ロボットの制御システムを作成する場合、平均的な携帯電話アプリケーションを作成するときと同じようには機能しません。NorvigのTeach your programming in 10 yearsページも参照してください。

私が心に留めておきたい3つのモットーがあります。

• 「すべてをできるだけシンプルにする必要がありますが、シンプルではありません」

  「1つまたは2つのクラス」の例を挙げると、「どちらが簡単な解決策ですか？」

• 「明らかなバグなし」対「明らかにバグなし」

  後者が望ましい！

  そして、それがシンプルである必要がある理由です。つまり、あなたはそれについて推論することができます。1つの大きなクラスは大きすぎて複雑すぎて推論できない場合があります。その場合、それをいくつかの小さなクラスに分割します。そのインターフェースはシンプルで、正しい方法で組み合わされています。」

  1. コードは理論的に（つまり、頭の中で）実行する必要があります。
  2. その後、実際に機能しない場合は、実際に理論と一致するまでデバッグできます。

  ただし、初心者はステップ1を気にしない場合があります。つまり、頭で実行すること（複雑すぎるなど）-しかし、その場合、「理論上」ではなく「偶然」に実行されます。明白ではないバグを見つけるのに十分なテストを行いました。

• ゴールの法則

  これは別名「リファクタリング」です。

  実際には、これは次のことを意味します。

  1. 動作する[ny]シンプルなシステムから始めます
  2. 次は、新しい機能を追加します
  3. 既存のシステムをリファクタリングして、新しい機能を簡単に追加できるようにします。

  4. 新しい機能を追加する

  5. ...そして上記のように繰り返します

  これは、YAGNIのようなモットーに一致します。つまり、必要になる前にリファクタリング（アーキテクチャを心配）しないでください。ただし、特定の目的で必要なときに適切なアーキテクチャを作成します。

できることは、必要な抽象化の最小数から始めることです。たとえば、1つのファイルのPersonクラス。コードと機能を追加し続けると、別の抽象化に移動する必要があるものが見え始めます。たとえば、単一責任原則（S of SOLID）は、Personクラスにアドレス解析に関連するメソッドがないことを示しています。これで、Addressクラスが必要であることがわかりました。

しかし、システムにとって「最小数の抽象化」がどのように見えるかについて考えるのに、少し時間をかけることは常に良いことです。十分に優れたアーキテクチャーから始めて、改善していきます。

編集：@Basileの回答は、最小アーキテクチャを繰り返して改善する方法の例を示しています。

システムのアーキテクチャを考えるのに費やす時間は無駄ではありません。

あなたの質問は、「アーキテクチャの決定をより効率的に行うにはどうすればよいですか」と言い換えることができると思います。

それに対する私の短い答えは次のとおりです。あなたはあなたがあなたが確実にそして効率的に意思決定をすることを可能にするコア原則を発見する必要があり、それからあなたは実際に外に出て実際のソフトウェアを形作る必要があるでしょう。これは、知識、試行錯誤、および自己啓発を求める長い道のりです。

-

そして、より長い答えのために...

最初に概念を明確にする必要があります。プロセス、サービス、API、およびデータベースを扱うときは、アーキテクチャという言葉を使用して複雑なソフトウェアシステムの構造を説明します。クラス、関数、およびライブラリを使用している場合、デザインという言葉を使用して、より複雑なシステムのうちの1つだけの構造を説明します。これらは私の定義であり、一部の人々は異なる定義を持っています。しかし、この文脈では、デザインについて話していると思います。

このトピックを議論する際に留意すべき3つの重要なことがあると思います。

• アーキテクチャと設計は、図やドキュメントを介して明示的に記述されることなく、チームや個人（アーキテクト）によって保守されることなく存在します。どのシステムにも、事後的に説明できる固有のアーキテクチャと固有の設計があります。

• ソフトウェア開発はプログラミングではなく、時間の経過とともにプログラミングされます。私がこの区別をしているのは、それが業界にやってくる人々にとって最大の盲点の1つだと思うからです（私自身もある時点で含まれています）。これが意味することは、大学のプロジェクトや個人的なサイドプロジェクトと比較して、実際のソフトウェアシステムでの作業は指数関数的に複雑になっているということです。これで、あなたの決定があなたを悩ませるようになります。

• アーキテクチャと設計は本質的に存在し、コードベースは時間とともに進化する生き物であるため、アーキテクチャと設計も進化する必要があります。それらは、コレクト時に行われた意識的な決定を通じて制御された方法で進化するか、コーディングによって混乱して進化します。これは、「最初に建築家、次に2番目にコードを書く」という従来のアプローチに欠陥があるため、理解することが重要です。もちろん、ゼロからプロジェクトを開始する場合、アーキテクチャおよび設計作業の一部を事前に行う必要があります。しかし、それ以外にも、システムの開発中に行うべき多くのアーキテクチャおよび設計上の決定があります。

さらに、上記蒸留するために、あなたがいるという事実を認識することが非常に重要であるだろうコードを書いている間のいずれか意識的かどうか、設計上の意思決定を行うこと。これらの決定の多くを意識的かつ批判的に行うように努力する必要があります。軽度の決定は将来の作業に大きな影響を与える可能性があります（この影響は通常、バグを修正したり機能を実装するためにコードベースを変更するのが非常に困難になることで現れます）。ロバートC.マーティンは、これをデータとともに、彼の著書 "Clean Architecture"（私が強くお勧めします）で美しく説明しています。

アーキテクチャと設計が重要である理由がわかったので、適切な意思決定のための適切なフレームワークを提供できる中核となる原則は何ですか？キャリアの早い段階でこの質問がありました。ツールセットに何か不足しているように感じましたが、何を知らないか、どのように説明するか、それを探しに行きませんでした。私が時間とともに発見したこれらの原則のいくつかを共有し、あなたの人生が少し楽になることを願っています：

• Martin Fowlerの本「Refactoring：Improving the Design of Existing Code」を読むと、非常にシンプルだが強力なコーディングトリックのセットを拾うことができます。ここにリストするには多すぎますが、これらは非常に低レベルのコーディング時の決定であり、コード構造を大幅に改善し、設計上の決定を下すのに役立ちます。この本は、ユニットテストを個人のワークフローに統合し、テスト可能なコードを記述する方法にも適しています。

• 特にOOPについては、SOLID原則を確認する必要があります。それらは少し抽象的で、最初は心を包むのが難しいですが、非常に強力です。最初の2から始めて、すぐに最大の利益を得ることができます。

単一責任の原則：クラスには単一の責任のみが必要です（つまり、ソフトウェアの仕様の一部への変更のみがクラスの仕様に影響を与えることができます）。

オープン/クローズの原則：「ソフトウェアエンティティ…は、拡張のために開かれ、修正のために閉じられる必要があります。」

• 継承よりも構成の概念

  クラスは、基本クラスまたは親クラスからの継承ではなく、ポリモーフィックな動作とコードの再利用（目的の機能を実装する他のクラスのインスタンスを含む）によってコードを再利用するという原則。

• 結合の概念（「ソフトウェアモジュール間の相互依存の程度」）と結合（「モジュール内の要素が一緒に属する程度」）
• DRY（自分を繰り返してはいけない）という概念
• コマンド/クエリ分離概念（「すべての方法のいずれかを行うアクション、またはクエリその戻りデータ呼び出し元へのコマンドであるべきであるが、両方ではありません」）
• ステートフルシステムとステートレスシステムの概念（私の経験則では、状態の処理を避け、可能な限りステートレスシステムを構築します）。

もちろん、これらはルールではなく概念です。最初のステップは、それらを理解し、それらを認識することです。次に、実際にそれらを実際に使用し、従うべきときとそうでないときの経験を構築します。そして、これらの概念、それらのネガティブな側面、相互の複雑な相互作用についての理解を深める継続的なプロセスがあります。

私があなたに与えることができる最も貴重なアドバイスは、自分自身に忍耐を持つことだと思います。長くて充実した道を歩み始めたばかりです。練習と実験を続け、何がうまくいくか、何がうまくいかないかに注意してください。

説明するもののほとんどは、実際には（重要な）アーキテクチャではありません。適切な命名と適切なクラス設計は、あなたにとって2番目の性質であるはずです。これは、コーディングすればするほど良くなります。このような懸念に最も役立つのは、通常、ペアプログラミングです。これは、このような問題を明確にするのに役立ち、これを効率的に学習するのに役立ちます。

プロジェクトの前にアーキテクチャが必要な場合：

1. 正確な要件と非機能要件を収集します（1秒間に何件のリクエストをサポートする必要がありますか？）。このフェーズでのミスマッチはコーディングの地獄につながります-事実が時間を浪費し、迷惑で、時には不可能だった後に見逃したアイデアを統合します。これはコーディングとしては楽しいものではないことはわかっていますが、設計されていないことをコードで実行しようとすることはさらに面白くありません。

2. 適切な場合は、システムの境界コンテキストを定義し、語彙がまっすぐであることを確認します。たとえば、ビジネスが「Frobbels」について話している場合、「*** Frobbels」でクラス/インターフェイスなどに名前を付けます。些細なことのように聞こえますが、ワークフローについて話すと、ビジネスが操作について話す間、翻訳は非常に速く面倒になります。

3. 複数の人/チームと協力してインターフェースを早期に説明し、すべての前提条件と問題が全員に理解されるようにします。共有コンテキストがない場合、統合は「楽しい」でしょう。たとえば、バナナ画像ジェネレーターを作成しますが、フロントエンド開発者はリンゴ画像ジェネレーターを必要とします。または、100リクエスト/秒に応答できるものを構築しますが、10000 r /秒が必要です。

注：これは、マイクロサービスアーキテクチャに関する私の作業の影響を大きく受けています。サーブを内部で構築する方法、設計することもできますが、ほとんどの場合、全体像を正しく把握するよりも重要度は低くなります。

たくさんの用語や略語をあなたに投げかけるつもりはありません（それらのほとんどは、大部分のコーダー/ソフトウェアエンジニアによってほとんど同意されていません）。代わりに、次のことを考慮してください。

1. あなたは学んでいます-時間を無駄にせず、さまざまなアプローチを試し、何が効果的かを学んでいます。頭に浮かぶ最初のソリューションの問題に飛び込み、それがうまくいかない場合にそれを変更することにより、多くのことを事前に計画することなくこれを行うことができます。それがうまく機能する場合、素晴らしい！問題の簡単な解決策を見つけました。シンプルなソリューションは、うまく機能していれば問題ありませんし、時には十分である場合もあります。

2. すべてがトレードオフです-時間とスペース、複雑さと柔軟性、抽象化と読みやすさ、または可能な多くのトレードオフのいずれかをトレードオフする多くの異なる方法で同じシステムを設計できます。あらゆる点で完璧なソリューションはありません。また、ソフトウェアエンジニアリングにおいて例外のないルールはありません。そうでないとあなたが言う人は誰でも素朴であるか何かを売っています。

3. 最近の卒業生として、コーディングとデバッグは非常にエキサイティングなものになりますが、これは時間の経過とともに消えていきます。そして今学んでいるスキルは、そうすることであなたに役立つでしょう。

4. ソフトウェアを構築することは、エンジニアリングよりもアート/クラフトであると主張します。優れた芸術とは、個々のブラシストロークだけでなく、アーティスト/職人によって行われる高度な決定とトレードオフに関するものです。

私は、ウェブ開発の観点から来たこの質問に答えようとします（つまり、人々が建築に苦しむ分野から来ます）。まず、なぜ人々がアーキテクチャに関心を持っているのかを説明し、その後、アーキテクチャの部分をより早く通過する方法の概要を説明します。

アーキテクチャは、コードに対して2つのことを行います。

1. あなたや他の人のためにあなたのコードを理解しやすくします。
2. コードの拡張と統合を容易にする方法でコードを構造化するのに役立ちます。

コードスタイルを使用すると、コード内の特定の部分を簡単に読み取ることができます。コードスタイルを認識して使用すると、コード内を移動できます。同様に、優れたアーキテクチャは、特定の機能を処理するコードを実際に見つける場所を特定するのに役立ちます。たとえば、ほとんどのWebプロジェクトでは、アーキテクチャはフォルダとファイルのソート方法に密接に関連しています。反対に、優れたアーキテクチャは、コードについて考えることを実際に少なくするのに役立つはずです。なぜなら、コードの一部が属する直感的な場所がすでに用意されているはずだからです。

さらに、優れたアーキテクチャは、コードが簡単に使用されないという落とし穴の多くを回避するための速記を提供します。繰り返しになりますが、アーキテクチャを決定する場合は、コードの記述方法について考えることを少なくするための規則を設定する必要があります。

今あなたが実際にここにいる部分：

アーキテクチャ部分をより迅速に通過できるもの：

1. しないで

多くの答えがすでに指摘しているように。最初に、実際にアーキテクチャが必要かどうかを自問してください。コードがあまりない場合（そして、プロジェクトが近い将来に成長しないことを合理的に確信できる場合）、アーキテクチャ部分をスキップして、単純に機能するものを一緒にまとめることができます。しかし、もしあなたがあなたのキャリアの初期にいるなら、私は機会があればいつでも練習するでしょう。ある時点でより大きなプロジェクトを行うことになりますが、その時点で学習するのはおそらく遅すぎます。

それが邪魔にならないので、アーキテクチャの痛みを軽減するためにできることは何ですか：

1. 早くやる
2. スチール
3. 学ぶ/それにこだわる
4. 無理しないで

アーキテクチャを決定することは、計画プロセスの初期段階である必要があります。作成するアプリ/プログラム/ウェブサイトの種類がわかったら、すぐにこれをサポートするアーキテクチャの種類を検討する必要があります。

この時点で、恥知らずに盗む時間です。プログラムアーキテクチャを適切に設定する方法については多くの文献があり、これらの既存のアーキテクチャプロトタイプには驚くべき量のユースケースが含まれています。実装方法がわからなくても、どのようなアーキテクチャが存在するかについての大まかな概要を学ぶ必要があります。

ある種のアーキテクチャに落ち着いたなら、それに固執してください。ほとんどの場合、アーキテクチャの決定は直観的であり、初期設定後数秒で完了します。これの多くは経験に帰着します。

最後に、物事を考えすぎないでください。あなたは、何かがパブリックまたはプライベートであるべきかどうかの例を挙げます。真実は、すべてをパブリックにするかどうかはおそらく問題ではないということです。はい、このようにしてはいけません。これらの小さな間違いの多くは、しばらくすると山積みになりますが、一日の終わりにはおそらくプロジェクトを殺すことはないでしょう。何よりもまず、動作するソフトウェアを作成してください！

（PS：その最後の文は、怠beingであることの言い訳にはなりません。動作中のソフトウェアに優先順位を付けることは、いつか良いコーディングを学ぶ必要がないということではありません。）

答えはとても簡単です。

• プロトタイプを作成する（タイムボックス）
• リファクタリング（さまざまな要因に基づいて、必要な時間または必要な時間を費やします）

プロトタイプを作成するときは、最小限の実行可能な製品に焦点を合わせ、リファクタリングするときには、プロジェクトまたはソリューションをスケーラブルにすることに焦点を当てる必要があります。

アーキテクチャフェーズからコーディングとデバッグのフェーズに、より迅速に到達するにはどうすればよいですか？

このタスクを経験豊富な同僚に委任する（または支援を依頼する）ことにより。

そのような決定を迅速に行うために必要な経験が不足しているだけです。ユニはあなたに素晴らしい理論的背景を与えましたが、それはあなたをスタートラインに導くだけです。特定の状況で特定のアーキテクチャを判断する方法は、類似のアーキテクチャが過去に類似の状況でどのように動作したかを知ること以外にはありません。

あなたよりも仕事が上手な人と仕事をすることは、物事を学ぶための最速の方法です。頼れる先輩がいないなら、もっといい仕事が必要です。「より良い」「ニーズに合わせて」。あなたのジレンマによって証明されるように、知識と経験の必要性は、現時点であなたの最も切実な必要性です。コーディングとデバッグのフェーズを楽しんでいますか？完璧な後輩のようですね。しかし、ジュニアはシニアの指導が必要です。それがこれらの職務記述書のポイントです。インターネット上の見知らぬ人はこれまでのところあなたを助けることができます、あなたはメンターが必要です。

この質問には重大な問題がいくつかあります。始めましょう。

建築設計の時間を無駄にするのをやめる方法

この質問はかなりロードされます。また、アーキテクチャを設計しません。あなたは建築家。アーキテクチャと設計は補完的で関連するアクティビティですが、重複する場合でも同じではありません。

同様に、アーキテクチャの実行に時間を浪費すること（オーバーアーキテクト化による）と同様に、過剰な設計とオーバーコーディングに時間を浪費することもできます（必要以上に複雑な方法でコードをコーディングすることにより、または必要なもののコード。）

適切なアーキテクチャは、コーディングの無駄を防ぐことを目的としています。複雑なシステムを1）設計、2）コード化およびテスト、3）配信、4）メンテナンス、5）障害からの回復、および6）最終的な廃止の可能な方法を制限、絞り込み、文書化します。

私の経験では、されているだけで、彼らはただコーディング楽しむ人々そのコードをシステムが動作し、次へ移動、長期的に維持することがいかにの任意の考えなしにホットポテト醜いゴーレムを維持するために、いくつかの貧しい人々の魂を残します。

しかし、私は脱線します...

これが重要なことです。十分に単純なシステムの場合、アーキテクチャは自明であり、適切な設計と実装の実践から発します。

これは、かなり多数の人が関与する大規模システムや、明示的なアーキテクチャを必要とする非常に複雑な処理を行うシステムレベルのソフトウェア専用です。

私は最近、大学を卒業し、プログラマーとして働き始めました。「技術的な」問題を解決したり、デバッグをしたりするのはそれほど難しいことではありません。

これがこの職業に最低限必要なものであり、あなたがそれらを行うのに問題がないことをうれしく思います（もしあなたがそうしたら心配するでしょう）。

しかし、1つの解決策を持たない問題のクラスがあるようです

これらは私たちの職業の基本であり、雇用主が私たちの（通常）平均以上の給与を喜んで支払う問題のタイプです。

実際のところ、解決する価値のある問題は、複数の解決策を持つことができる問題です。現実世界の問題、彼らはそのようなものです。そして、世界では、許容できるトレードオフを考え出すために、ソフトウェア開発者としての専門知識が必要です。

-ソフトウェアアーキテクチャなど。

物事のアーキテクチャは、仮想/ソフトウェアであろうと具体的な世界であろうと、複雑なシステムの避けられない特性です。動作し、入力を受け取り、出力を生成するすべてのシステムは複雑で、アーキテクチャを備えています。

このようなシステム（銀行システム、電力監視システム、チケット販売システムなど）のソフトウェアを開発するとき、そのようなシステムの機能と要件を模倣するソフトウェアを作成することを目指しています。

私たちは単にそれを翼にして、カウボーイスタイルでコーディングすることはできません。何らかのアーキテクチャが必要です。これは、プロジェクトが数十人のエンジニアを必要とする場合に特に当てはまります。

これらのことは私を混乱させ、大きな苦痛を引き起こします。

それは大丈夫です。学ぶことや教えることは簡単なことではなく、多くの練習が必要です。

私は自分のプログラムとシステムをどのように「アーキテクト化」するかを決めるのに何時間も費やしています。たとえば、このロジックを1つまたは2つのクラスに分割したり、クラスにどのように名前を付けたり、プライベートまたはパブリックにしたりする必要があるかなどです。私はプログラムを作成したいだけで、アーキテクチャはとんでもないものです。

残念ながら、それはソフトウェアアーキテクチャではありません。

デザインではなく、コーディングだけです。この投稿の最後にいくつかの提案を提供します。

どうすれば、より迅速に、アーキテクチャ段階は通過し、コーディングとデバッグ相上に取得することができ、私は楽しんでいますか？

私はこれに答える方法を見つけるのに苦労しています。それはむしろ感情的なものだからです。

私たちは仕事を成し遂げようとしているのか、それともただ練習を楽しんでいるだけなのか？両方が同一である場合は素晴らしいことですが、実際の生活では多くの場合そうではありません。

私たちが楽しむことをするのは素晴らしいことですが、私たちのような複雑な職業で、私たちが楽しんでいることに集中することは、実りあるキャリアを持つために伝導的ではありません。

進歩したり、成熟したり、新しい知識を獲得したりすることはありません。

軍隊には「吸うことを受け入れる」という言葉があります。

他のフレーズにも同様のアドバイスがあります。「それが吸わないなら、それは価値がない」と私のお気に入り、「それが吸う（そしてそれが重要である）なら、吸うのをやめるまでそれをしてください。」

私の推奨事項：

あなたはまだ違いを理解するのに苦労しているように思えます

1. コーディング（クラス、モジュール、またはそうでないもののコーディング方法、命名規則、アクセスの可視性、スコープなど）、

2. 設計（層数、フロントエンド/バックエンド/ db、各通信方法、どこへ行くか）および単純なシステムの設計から生じる暗黙的なアーキテクチャの決定、

3. アーキテクチャ（数十万時間ではないにしても、数千時間を要する複雑なシステムに見られる）

したがって、次のレベルに進むために、最初の主題（コーディング）を深く掘り下げることをお勧めします。

きれいなコード

Robert "Uncle Bob" Martinの"Clean Code"は開始するのに適した場所です。

ソフトウェアの凝集

さらに、LCOMまたはLCOM4と呼ばれる特定のオブジェクト指向ソフトウェアメトリックに精通することをお勧めします。

それはかなり数学的になる可能性があり、防弾ではありませんが、あなたの目標は、クラスが凝集しているか凝集していないかを経験的に理解して検出することです（または、必要に応じて目玉）。

http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4 https://www.computing.dcu.ie/~renaat/ca421/LCOM.html

ソフトウェアの原則

これは、私たち全員がよく知っているべき「単一責任原則」またはSRY と密接に関連しています。SRYは、コーディングに習熟するために必要な5つの「ソリッド」の 1つです。

SOLIDの原則を順を追って進めると、クラスをコーディングする方法を管理する、またはむしろガイドする「GRASP」の原則にも慣れる必要があります。

追加の本

最後に、次のこともお勧めします。

• Martin FowlerとKen Beckによる「リファクタリング」は、このリストで次に読む本です。

• Richard Mitchell、Jim McKim、Bertrand Meyer（エッフェルの名声の後半）による「Design by Contract、by Example」。この本は絶版ですが、Amazonで安価な中古品を見つけることができます。

これにより、コーディングと設計を開始する方法をよく理解し、実際にソフトウェアアーキテクチャを移動してマスターする（または少なくとも把握する）必要があります。

これらの提案に追加、削除、または反対する他の専門家がいると確信しています。彼らは、おそらく彼ら自身の経験によって検証された他の提案を思いつくでしょう。

私が言えることはこれだけです-近道はありません。

ではごきげんよう。

ここには多くの情報があり、率直に言ってTL; DRです。システムの設計方法を学ぼうとするとき、人が間違っていると思う主な点が1つあります。彼らは、作業が行われる順序でそれについて考えようとします。代わりに、後方に作業する必要があります。つまり、設計/アーキテクチャの主な目標は、最終結果がどうあるべきかを判断することです。

例えとして、家の建築を考えてみましょう。建築家は、「この家にはどのくらいの窓が必要ですか？」、「最初のレンガをどこに置くべきですか？」などの質問を始めません。これらの実装の詳細は設計ではなく、設計から派生しています。建築はビジョンから始まります。完成した家がどのように見えるかについてのスケッチかもしれません。それは一戸建ての家、二重ですか？豪華な家ですか、それとも手頃な価格の家ですか？同様に、変数がプライベートであるかどうか、およびクラスを分割するかどうかは、アーキテクチャとはほとんど関係ありません。

まず、設計の目標が何であるかを把握することから始めます。たとえば、これは1回限りのソリューションですか？それは数十年にわたって拡張され、修正され、維持されますか？その答えは、非常に異なるデザインを示し、それがアーキテクチャのポイントです。必要なことを理解したら、設計の詳細は自然に続きます。これらの詳細が明白または簡単であるというわけではありませんが、これらの選択が基づいているのは高レベルの計画です。

ある種のwrite-compile-testループを取得する前に、ソフトウェアの設計にどれだけの時間を割くべきかを判断する方法は、非常に簡単です。あなたが取り組んでいるプロジェクトがより厳密な方法論を要求していない限り。どちらの場合でも、初心者としては、アーキテクチャドキュメントを読むのではなく、読むべきです。

物事の命名に関しては、私にとってそれは「書く」ことの一部ですが、それは間違いなくプログラミングの非常に重要な部分です。

適切な名前、適切なアーキテクチャ、適切なモジュール性、適切な抽象化を見つけることは、間違いを犯すことで得られる経験の一部です。長年にわたって、同じことを約5回実行するプログラムを書いてきましたが、コードは毎回非常に異なっていました。