アーキテクチャの設計に時間を費やすのをやめる方法
私は最近大学を卒業し、プログラマーとして働き始めました。 「技術的な」問題を解決したり、1つの解決策があると私が思うようなことでデバッグしたりするのは難しいとは思いません。
しかし、ソフトウェアアーキテクチャのように、しないでくださいに1つの明確な解決策があるクラスの問題があるようです。これらは私を困惑させ、私に大きな苦痛を与えます。
私はプログラムとシステムをどのように「構築する」かを決めるために何時間も費やしています。たとえば、このロジックを1つまたは2つのクラスに分割しますか、クラスにどのように名前を付けますか、これをプライベートまたはパブリックにする必要がありますか。私はプログラムを作成したいだけです-アーキテクチャはのろわれます。
どうすればアーキテクチャフェーズをより迅速に完了し、楽しんでいるコーディングおよびデバッグフェーズに進むことができますか？
完璧は善の敵です。
とはいえ、手を抜いてはいけません。ソフトウェア設計は、より長期的な影響を与え、将来的に（そしてあなたの仲間）の膨大な時間と労力を節約します。正しくなるには時間がかかります。ほとんどの時間はプログラミングに費やされましたされていませんキーボードを叩いていますが、ホワイトボードで問題を解決する方法を理解しています。
しかし、完璧さについても心配する必要はありません。 2つのデザインが行き詰まって戦う場合、それはそれらがほぼ同じ良さであることを意味します。一つで行く。その設計の欠陥を見つけたら、変更できないというわけではありません。
（うまくいけば、技術的な問題をデバッグ/解決する方法が1つだけではないことがわかったら、それも役に立ちます。）
シンプルで小さなプログラムの場合（たとえば、ソースコードが1万行未満の場合）、コードを記述しながらそれらを設計できます。 反復的かつ段階的な開発 アプローチを採用する場合、その過程で次第にアーキテクチャ上の決定を行います。数十行のコードを記述し（単一のマイクロ機能を追加）、コンパイラーから警告が返されなくなるまで改善し、デバッガーでテストして、繰り返します。
このロジックを1つまたは2つのクラスに分割しますか、クラスに名前を付ける方法、プライベートにするかパブリックにするか、など。これらの種類の質問は私の時間の多くを占めます
彼らはすべきではない。そしてsmallプログラムの場合はそれほど重要ではありません（小さくて単純なプログラムの方が簡単だからです）改善する、例えば名前を変更するなど...）。一貫性があり、ソースコードのreadabilityを優先する必要があるだけです。場合によっては、プログラムのわずかな部分 refactor の小さな部分（そして大きくない対処）。
これを多くの 無料ソフトウェア プロジェクト（Linuxカーネルのような大きなプロジェクトでさえ）と比較してください。開発者は初期段階で「設計」に多大な労力を費やしませんでした。 UMLはフリーソフトウェアで使用されることはほとんどありません 。さらに、いくつかのフリーソフトウェアプロジェクトのソースコードを学習することで、かなりのことを学びます。
初心者は、チームで大規模なソフトウェアプロジェクトに取り組み、上級の開発者（アーキテクチャの決定を行う）を信頼するか、小規模なプロジェクト（通常、数十万人未満）に単独で取り組みます。ソースコードの行）。後者の場合、段階的にアーキテクチャーに関する決定を行い、アプリケーションを時々リファクタリングします。その後、「アーキテクチャー設計」は自然に進化します。
どうすれば、アーキテクチャフェーズから、コーディングとデバッグフェーズにすばやく移行できますか。
1年もかからない小さなソフトウェアプロジェクトの場合、非常に簡単に：アーキテクチャを実行しないでください。全体でおそらく30分ブレーンストーミングを行います設計。次に、 反復および増分開発 アプローチを使用してコードの記述を開始します。数十行を記述してコンパイルします（すべての警告とデバッグ情報を有効にして、たとえばg++ -Wall -Wextra -g with [〜＃〜] gcc [〜＃〜] C++の場合）警告が表示されなくなるまで（そして、もしあれば、いくつかの単純な静的ソースコードアナライザーでそれを渡します。例： clang-analyzer ）、 debugger でそのコードをテストし、 version control にコミットします（例 git ）、すすぎ、繰り返します。ただし、 技術的負債 は避けてください。臭いがする場合は、（リファクタリングと再実装によって）改善してください。
一方、チーム環境では、アーキテクチャー作業はすべてのチームメンバーの責任を定義するための最初の議論を伴います。その議論は上級開発者（初心者ではない）が主導しています。 アジャイルソフトウェア開発 および The Mythical Man-Month についてお読みください。
プログラムを作成したいだけなのですが、アーキテクチャはおかしくなっています。
優れた直感（少なくとも小規模なプロジェクトの場合）。したがって、プログラムについて数分考え、 反復的で段階的な開発 アプローチでコーディングを開始します。数十行をコーディングし、それらが適切に機能することを確認してから繰り返します。その前に、同様のフリーソフトウェアプロジェクトのソースコードを調べ（そしてアーキテクチャを観察し）、より一般的には書誌的作業と調査を行います。
いくつかの場合、 metaprogramming アプローチについて考えてください：generateいくつかの「ソースファイル」（ bison などのパーサージェネレーター、 [〜＃〜] swig [〜＃〜]などのグルーコードジェネレーターの使用例 、Google protobuf 、そして単純なスクリプトを記述したり、 [〜＃〜] gpp [ 〜＃〜] -繰り返しコーディングを避けるためにC++またはJavaコードの一部を出力します）。
PS。私はリサーチエンジニアであり、コンピュータサイエンスの博士号と40年の経験があります。中規模プロジェクトやいくつかの大規模プロジェクト（GCCコンパイラ自体）で成功している間、あなたの質問が示唆するような「アーキテクチャ」を実行したことはありません。 ）。私にとって「アーキテクチャ」は、次の数日または数週間の作業の計画段階にすぎません（そして、私は通常、夢を見たり寝たりしながら、確かにコンピュータを使わずに、通常は鉛筆さえも使わずにそれを行います）。また、 research grants を書くとき、私はどういうわけか不完全にアーキテクチャを設計しています。
注意：一部のソフトウェアプロジェクトでは、他のプロジェクトよりも多くのアーキテクチャが必要です。たとえば、人工心臓や脳神経外科ロボットの制御システムを作成する場合、平均的な携帯電話アプリケーションを作成する場合と同じようには機能しません。 Norvigの 10年間でプログラミングを学ぶ ページも参照してください。
覚えておきたいモットーは3つあります。
「すべてを可能な限りシンプルにする必要がありますが、シンプルにする必要はありません」
「1クラスか2クラスか？」
「明らかなバグなし」対「明らかにバグなし」
後者が望ましいです！
そして、それがシンプルである必要がある理由です。つまり、あなたはそれについて推論することができます。 1つの大きなクラスが大きすぎたり、複雑すぎて推論できなかったりする場合があります。その場合は、クラスをいくつかの小さなクラスに分割します。そしてそれらのインターフェースはシンプルであり、それらは正しい方法で組み合わされます。」
- コードは理論的に実行する必要があります（つまり、頭の中で）。
- 次に、実際に機能しない場合は、理論と一致するまでデバッグできます。
初心者は、ステップ1を気にしない場合があります。つまり、頭の中で実行する（例：複雑すぎるため）-しかし、その場合、「理論上」ではなく、「偶然」にしか実行されていません。 t明らかでないバグを見つけるのに十分なテストを行いました。
これは別名「リファクタリング」です。
実際には、これは次のことを意味します。
- 機能するシンプルなシステムから始めます
- 次に、新しい機能を追加します
- 新しい機能を簡単に追加できるように（つまり、まで）既存のシステムをリファクタリングする
新しい機能を追加する
...そして上記のように繰り返します
これは、YAGNIのようなモットーと一致します。つまり、必要になる前に（アーキテクチャについて心配することなく）リファクタリングしないでください。ただし、特定の目的で必要なときに、適切なアーキテクチャを適切なタイミングで作成してください.
あなたができることは、必要な抽象化の最小数から始めることです。たとえば、1つのファイル内のPersonクラス。コードと機能を追加し続けると、別の抽象化に移行する必要があるものが見えてきます。たとえば、単一責任の原則（SOLIDのS）は、Personクラスのアドレス解析に関連するメソッドを持たないように指示します。これで、Addressクラスが必要であることがわかりました。
ただし、システムの「最小数の抽象化」がどのように見えるかについては、少し時間をかけて考えるのがよいでしょう。十分に優れたアーキテクチャから始めて、必要に応じてそれを改善してください。
編集：@Basileの回答は、最小限のアーキテクチャを反復して改善する方法の例を示しています。
システムのアーキテクチャを考えるのに費やされた時間は、時間の浪費ではありません。
あなたの質問は、「どのようにしてアーキテクチャの決定を行う際に、より効率的になることができるのか」と言い換えることができると思います。
それに対する私の短い答えは、あなたは信頼性があり効率的に決定を下すことを可能にするコア原則を発見する必要があり、次に実際に出て実際のソフトウェアを形作る必要があるということです。これは、知識、試行錯誤、個人的な成長を求める長い道のりとなるでしょう。
-
そしてより長い答えのために...
最初に概念を明確にする必要があります。プロセス、サービス、API、およびデータベースを使用しているときは、Word architecture を使用して複雑なソフトウェアシステムの構造を説明します。クラス、関数、およびライブラリを使用しているときは、より複雑なシステムから1つだけの構造を説明するためにWord design を使用します。これらは私の定義ですが、一部の人々は異なる定義を持っています。しかし、この文脈では、あなたは design について話していると思います。
このトピックについて話し合う際に留意すべき重要なことが3つあると思います。
アーキテクチャとデザインは、図やドキュメントを介して明示的に記述されることなく存在し、またチームまたは個人（ architect ）によって維持されることもありません。どのシステムにも、事後的に説明できる固有のアーキテクチャと固有の設計があります。
ソフトウェア開発はプログラミングではなく、時間の経過に伴うプログラミングです。これは、業界に参入する人々にとって最大の盲点の1つだと私が考えているためです（ある時点では、私自身も含まれています）。これが意味することは、大学のプロジェクトや個人のサイドプロジェクトと比較して、実際のソフトウェアシステムでの作業は指数関数的に複雑になります。これは、アーキテクチャ上の決定は、時間とともにシステムの開発に大きな影響を与えるためです。あなたの決定は今、あなたを悩ませるために戻ってきます、保証されます。
アーキテクチャとデザインは本質的に存在し、コードベースは時間とともに進化する生き物であるため、アーキテクチャとデザインも進化する必要があります。それらは、正しい時期に行われた意識的な決定を通じて制御された方法で進化するか、コーディングによって駆動されて無秩序に進化します。これは、「最初にアーキテクト、次にコードを書く」という従来のアプローチには欠陥があることを意味するため、理解することが重要です。もちろん、プロジェクトを最初から開始する場合、いくつかの建築および設計作業を事前に行う必要があります。しかし、それ以外には、システムの開発中にはまだ多くのアーキテクチャ上および設計上の決定が必要になります。
上記をさらに掘り下げるには、意識的に、または意識せずに、コードを書くときにwillが設計上の決定を行うという事実を認識することが非常に重要です。軽度に行われた決定は将来の作業に大きな影響を与える可能性があるため、これらの決定の多くを意識的かつ批判的に行うように努力する必要があります（この影響は通常、バグの修正や機能の実装のためにコードベースを変更することが非常に困難になるためです）。 Robert C. Martinは、彼の著書 "Clean Architecture"（ちなみに私が強くお勧めします）で、データを使ってこれを美しく説明しています。
それでは、アーキテクチャとデザインが重要である理由を理解したところで、適切な意思決定のための適切なフレームワークを提供できるコア原則は何ですか？私のキャリアの前半でこの質問がありました。ツールセットに足りないがあるように感じましたが、何を知っているか、それを説明する方法がわからないか、探しに行きませんでした。私が時間とともに発見したこれらの原則のいくつかを共有し、それらがあなたの人生をわずかに楽にすることを願っています：
martin Fowlerの著書「リファクタリング：既存のコードのデザインを改善する」を読むことで、非常にシンプルだが強力なコーディングトリックのセットをピックアップできます。ここにリストするには多すぎますが、これらは非常に低レベルのコーディング時の決定であり、コード構造を大幅に改善し、設計上の決定を行うのに役立ちます。この本はまた、単体テストを個人のワークフローに統合し、テスト可能なコードを作成する方法を説明する良い例にもなっています。
特にOOPについては、 SOLIDの原則 を確認する必要があります。これらは少し抽象的で、最初は心を包むのは難しいですが、非常に強力です。すぐに最大のメリットを得るには、最初の2つから始めることをお勧めします。
単一の責任の原則：クラスは単一の責任のみを持つ必要があります（つまり、ソフトウェアの仕様の一部への変更のみがクラスの仕様に影響を与えることができます）。
オープン/クローズドプリンシパル：「ソフトウェアエンティティ…拡張用に開いている必要がありますが、変更のために閉じています。」
- 継承に関する構成 の概念
クラスが、基本クラスまたは親クラスからの継承ではなく、（必要な機能を実装する他のクラスのインスタンスを含めることにより）構成によって多態性の動作とコードの再利用を実現するという原則。
- coupling （ "ソフトウェアモジュール間の相互依存度"）および cohesion （ "モジュール内の要素が一緒に属する度合い。"）の概念
- DRY（Do n't Repeat Yourself）コンセプト
- コマンド/クエリの分離の概念 （ "すべてのメソッドは、アクションを実行するコマンドか、呼び出し元にデータを返すクエリのいずれかである必要があります。両方ではありません。"）
- ステートフルシステムとステートレスシステム の概念（私の経験則は、状態の処理を避け、可能な限りステートレスシステムを構築する）です。
もちろん、これらは単なる概念であり、ルールではありません。最初のステップは、それらを理解し、それらを認識することです。次に、実際にそれらを実際に使用し、フォローする必要がある場合とフォローしない場合の経験を積み上げます。そして、これらの概念、その否定的な側面、および相互の複雑な相互作用についての理解を深めるための継続的なプロセスがあります。
私があなたに与えることができる最も価値のあるアドバイスは、自分自身に忍耐を持つことだと思います。あなたは長く、しかし充実した道を歩み始めました。練習と実験を続け、何が機能し何が機能しないかに注意してください。そうすれば、時間の経過とともに良くなります。
あなたが説明するもののほとんどは実際には（重要な）アーキテクチャではありません-優れたネーミングと優れたクラス設計はあなたにとって第二の性質であるべきものです。これは、コードを記述すればするほど改善されます。このような懸念に最も役立つのは、通常ペアプログラミングです。これは、そのような問題を明確にし、効率的に学習するのに役立ちます。
プロジェクトの前にアーキテクチャが必要な場合：
正確な要件と機能以外の要件を収集します（サポートする必要がある要求/秒の数）。このフェーズでのミスマッチはコーディングの地獄につながります-失敗したアイデアを統合するのに時間がかかり、煩わしく、時には不可能になるためです。これはコーディングとしては楽しいものではないことは知っていますが、コードが意図していない何かをするようにコードを取得しようとすると、さらに面白くなくなります。
適切な場合は、システムの境界付きコンテキストを定義し、語彙が正しいことを確認してください。たとえば、ビジネスが「Frobbels」について話している場合は、クラスやインターフェイスなどに「*** Frobbels」という名前を付けてください。些細なことのように聞こえるかもしれませんが、ワークフローについて話し、ビジネスが操作について話している場合、翻訳は非常に速く煩わしくなります。
複数の人/チームと協力して作業する場合は、インターフェースを早い段階で記述し、すべての前提と問題が全員に理解されるようにします。共有コンテキストがない場合、統合は「楽しい」ものになります。例えば。バナナ画像ジェネレータを作成しますが、フロントエンド開発者はApple画像ジェネレータを必要とします。または、100リクエスト/秒に応答できるものを作成しますが、10000 r /秒が必要です。
注：これは、マイクロサービスアーキテクチャに関する私の作業に大きく影響されます。サービスがどのように内部で構築されるかは、設計することもできますが、ほとんどの場合、全体像を正しくすることほど重要ではありません。
私はあなたにたくさんの用語と略語を投げるつもりはありません（それらのほとんどは、大多数のコーダー/ソフトウェアエンジニアによってほとんど合意されていません）。代わりに、以下を検討してください。
あなたは学んでいる-あなたは時間を無駄にしていない、あなたはさまざまなアプローチを試し、何がうまくいくかを学んでいる。頭に浮かぶ最初の解決策で問題に飛び込み、それが機能しない場合または変更することで、これを事前に計画することなく行うことができます。それがうまくいくなら、素晴らしい！問題の簡単な解決策を見つけました。単純な解決策は、うまく機能すれば問題なく、場合によっては十分に良いです。
すべてがトレードオフです。時間と空間、複雑さと柔軟性、抽象化と可読性、または可能な多くのトレードオフのいずれかをトレードオフして、同じシステムをさまざまな方法で設計できます。すべての点で完璧なソリューションはなく、ソフトウェアエンジニアリングの例外がないわけではありません。そうでないとあなたに言う人は誰でも、素朴であるか何かを売っています。
最近の卒業生として、コーディングとデバッグは非常にエキサイティングなものになる可能性がありますが、これは時間とともにすり減り、今学んでいるスキルはうまくいくときに役に立ちます。
ソフトウェアの構築はエンジニアリングよりもアート/クラフトであると私は主張します。優れた芸術とは、個々の筆運びだけではなく、アーティスト/職人による高レベルの決定とトレードオフです。
この質問には、Web開発の観点から（つまり、人々がアーキテクチャーに非常に苦労している分野から）答えるようにします。人々がなぜ建築を気にするのかを説明することから始め、次に建築部分をより早く乗り越える方法を概説します。
アーキテクチャは、コードに対して2つのことを行います。
- 自分や他の人が自分のコードを理解しやすくなります。
- コードの拡張と統合を容易にする方法でコードを構造化するのに役立ちます。
コードスタイルを使用すると、コードをナビゲートするために認識および使用できる規則が提供されるため、コードの特定の部分を読みやすくなります。同様に、優れたアーキテクチャは、特定の機能を処理するコードが実際にどこにあるかを特定するのに役立ちます。たとえば、ほとんどのWebプロジェクトでは、アーキテクチャはフォルダとファイルの並べ替え方法と密接に関連しています。逆に言えば、優れたアーキテクチャーは、コードの一部が属する直感的な場所をすでに備えている必要があるため、実際にはコードについてあまり考えないようにする必要があります。
さらに、優れたアーキテクチャは、コードが簡単に使用されないようにする可能性のある多くの落とし穴を回避するための速記を提供します。この場合も、アーキテクチャを決定する場合は、コードの記述方法についてあまり考えないようにするための規則を設定する必要があります。
今あなたが実際にここにいる部分：
アーキテクチャ部分をより迅速に通過するにはどうすればよいですか。
- やらないで
多くの答えがすでに指摘しているように。まず、実際にアーキテクチャが必要かどうかを自問してください。コードがあまりない場合（およびプロジェクトが近い将来に成長しないことを合理的に確信できる場合）、アーキテクチャの部分をスキップして、単純に機能するものをまとめることができます。しかし、あなたがあなたのキャリアの早い段階にいるなら、私はできる限りいつでも練習する機会を利用します。ある時点で、より大きなプロジェクトを行うことになりますが、その時点でおそらく学ぶのが遅くなります。
それを解決するために、アーキテクチャをより簡単にするために何ができますか？
- 早くして
- スチール
- 学ぶ/それにこだわる
- 無理しないで
アーキテクチャの決定は、計画プロセスの早い段階で行う必要があります。どのような種類のアプリ、プログラム、またはWebサイトを作成するかがわかったら、これをサポートするアーキテクチャの種類を検討する必要があります。
この時点で、むやみに盗む時が来ました。プログラムアーキテクチャを適切に設定する方法については多くの文献があり、驚異的な量のユースケースがこれらの既存のアーキテクチャプロトタイプでカバーされています。実装方法がわからなくても、どのような種類のアーキテクチャが存在するかをおおまかに把握する必要があります。
ある種のアーキテクチャーを選択した場合は、それに固執してください。ほとんどの場合、アーキテクチャの決定は直感的であり、初期セットアップから数秒しかかかりません。これの多くは経験に帰着します。
最後に、物事を考えすぎないでください。何かを公開するか非公開にするかの例を挙げますが、真実は、すべてを公開しても問題ではないということです。はい、このようにすべきではありません。これらの小さな間違いの多くは、しばらくすると山積みになりますが、結局のところ、プロジェクトを殺すことはないでしょう。何よりもまず、動作するソフトウェアを作成してください！
（追記：最後の文は怠惰であることの言い訳にはなりません。有効なソフトウェアを優先することは、いつか優れたコーディングを学ぶ必要がないという意味ではありません。）
答えは非常に簡単です。
- プロトタイプを作成する（時間ボックス化）
- リファクタリング（必要なだけの時間を費やすか、幅広い要因に基づいて費やす）
プロトタイプを作成するときは、最小限の実行可能な製品に焦点を当てる必要があり、リファクタリングするときは、プロジェクトまたはソリューションをスケーラブルにすることに焦点を当てる必要があります。
どうすれば、アーキテクチャフェーズから、コーディングとデバッグフェーズにすばやく移行できますか。
このタスクをあなたのより経験豊富な同僚に任せる（または助けを求める）ことによって。
そのような決定を迅速に行うために必要な経験が不足しているだけです。ユニはあなたに素晴らしい理論的背景を与えましたが、それはあなたをスタートラインに導くだけです。特定の状況で特定のアーキテクチャを判断する方法は、過去に同様の状況で同様のアーキテクチャがどのように動作したかを知ること以外にありません。
あなたよりも仕事が得意な人と協力することが、物事を学ぶ最も早い方法です。頼れる先輩がいない場合は、もっと良い仕事が必要です。 「あなたのニーズによりよく適合する」のように「より良い」。知識と経験の必要性は、ジレンマによって証明されているように、現時点で最も悲惨な必要性です。コーディングとデバッグのフェーズを楽しんでいますか？完璧なジュニアのように聞こえます。しかし、ジュニアはシニアの指導を必要とします。それがそれらの職務記述のポイントです。インターネット上の見知らぬ人は今のところあなたを助けることができるだけで、あなたにはメンターが必要です。
この質問には深刻な問題がいくつかあります。はじめましょう。
建築設計の時間を無駄にしない方法
この質問はかなりロードされています。また、あなたはdesignアーキテクチャを使用しません。あなた建築家。アーキテクチャとデザインは補完的で関連するアクティビティですが、重複する場合でも同じではありません。
同様に、（オーバーアーキテクチャによって）アーキテクチャの実行に時間を浪費する可能性があるのと同じように、（過剰に必要以上にコーディングするか、または必要なもののコード）
適切なアーキテクチャは、コーディングの無駄を防ぐことを目的としています。これは、複雑なシステムを1）設計し、2）コーディングしてテストし、3）配信し、4）維持し、5）障害から回復し、6）最終的に廃止する方法を制限、絞り込み、文書化することで実現します。
私の経験では、コーディングを楽しんでいる人は、システムがどのように動作し、長期的に維持され、次の状態に移行するかについて何も考えずにcodeだけですhot potato =醜いゴーレムを維持するために貧しい魂を残す。
しかし、私は余談です...
これが重要です：十分に単純なシステムの場合、アーキテクチャは自明であり、健全な設計と実装の実践から生まれます。
これは、かなり多数の人が関与する大規模なシステム、または明示的なアーキテクチャを必要とする非常に複雑な処理を実行するシステムレベルのソフトウェアのみを対象としています。
私は最近大学を卒業し、プログラマーとして働き始めました。 「技術的な」問題を解決したり、デバッグしたりするのが難しいとは思いません。1つの解決策があると思います。
それがこの職業に最低限必要なことであり、あなたがそれらを行うのに問題がなかったことを嬉しく思います（あなたがそうしたのであれば私は心配でしょう）
しかし、1つの解決策がないクラスの問題があるようです
それらは私たちの職業のパンとバターであり、雇用主が私たちの（典型的には）平均をはるかに超える給与を支払う用意がある問題のタイプです。
実際のところ、解決する価値のある問題は、複数の解決策を持つことができる問題です。現実世界の問題、それらはそのようなものです。そして世界は、ソフトウェア開発者としての私たちの専門知識を受け入れ可能なトレードオフを考え出すことを要求しています。
-ソフトウェアアーキテクチャなど。
物事のアーキテクチャは、仮想/ソフトウェアであろうと具体的な世界であろうと、複雑なシステムの必然的な特性です。動作し、入力を受け取り、出力を生成するすべてのシステムは複雑で、アーキテクチャーを持っています。
このようなシステム（銀行システム、電力監視システム、チケット販売システムなど）のソフトウェアを開発する場合、mimicsこのようなシステムの機能と要件を実現するソフトウェアを作成することを目指しています。
単純にwing itしてカウボーイスタイルにコーディングすることはできません。ある種のアーキテクチャが必要です。これは、プロジェクトに数十人のエンジニアが必要な場合は特にそうです。
これらは私を困惑させ、私に大きな苦痛を与えます。
それは大丈夫です。それは多くの練習なしではなく、学ぶことや教えることは容易な主題ではありません。
私はプログラムとシステムをどのように「構築する」かを決めるのに何時間も費やしています。たとえば、このロジックを1つまたは2つのクラスに分割しますか、クラスに名前を付ける方法、これをプライベートまたはパブリックにする必要があるかなどです。これらの種類の質問は私の時間の多くを占め、非常にイライラします。プログラムを作成したいだけなのですが、アーキテクチャはおろそかにされています。
残念ながら、それはソフトウェアアーキテクチャではありません。
それはデザインではなく、コーディングです。この投稿の最後にいくつかの提案をします。
どうすれば、アーキテクチャフェーズからコーディングおよびデバッグフェーズこれを楽しんでいるにすばやく移行できますか？
感情的になるので、これに答える方法を見つけるのに苦労しています。
私たちは仕事を成し遂げようとしているのですか、それとも練習を楽しむためだけなのですか？両方が同じ場合は素晴らしいですが、実際にはそうでない場合がよくあります。
私たちが楽しむことをするのは素晴らしいことですが、私たちのような複雑な職業では、楽しむことだけに集中することは、実りあるキャリアを持つために伝導的ではありません。
進歩せず、成熟したり、新しい知識を身につけたりすることはありません。
陸軍には、「しゃぶりを受け入れる」という格言があります。
他のフレーズにも同様のアドバイスがあります。 「それが吸えなければ、それは価値がありません」と私のお気に入り、「それが吸えば（そしてそれが重要です）、吸うのが止まるまでそれをしてください。」
私のおすすめ：
あなたはまだ違いを理解するのに苦労しているようです
コーディング（クラス、モジュールなどのコーディング方法、命名規則、アクセスの可視性、スコープなど）、
設計（層の数、フロントエンド/バックエンド/ db、それぞれがどのように通信するか、どこに行くか）、および単純なシステムの設計から得られる暗黙的なアーキテクチャーの決定
アーキテクチャ（数十万とは言わないまでも数千の工数を必要とする複雑なシステムで見られる）
したがって、最初の主題（コーディング）を深く掘り下げて、次のレベルに進むことをお勧めします。
クリーンなコード
Robert "Uncle Bob" Martinの "Clean Code" から始めるのが良いでしょう。
ソフトウェアのまとまり
さらに、LCOMまたはむしろLCOM4と呼ばれる特定のオブジェクト指向ソフトウェアメトリックに慣れることをお勧めします。
それはかなり数学的になる可能性があり、完全なものではありませんが、クラスが凝集性であるか凝集性に欠けているかを経験的に理解して検出する（または、希望する場合は眼球）ことを目標にする必要があります。
http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4https://www.computing.dcu.ie/~renaat/ca421 /LCOM.html
ソフトウェア原則
これは、誰もが知っている "単一の責任の原則" またはSRYと密接に関連しています。 SRYは5つのうちの1つです "SOLID" コーディングに熟練するためには、誰もが知っておく必要があることです。
SOLIDの原則に進むにつれ、クラスのコーディング方法を管理する、つまりガイドする "GRASP" の原則にも慣れる必要があります。
追加の本
最後に、次のこともお勧めします。
"リファクタリング" マーティンファウラーとケンベックの本は、このリストで次に読む本です。
"Design by Contract、by Example" Richard Mitchell、Jim McKim、Bertrand Meyer（Eiffelの名声の後半）。
これにより、コーディングと設計を開始する方法と、実際にソフトウェアアーキテクチャを移行して習得（または少なくとも把握）する方法をよく理解できます。
これらの提案に追加、削除、または反対する他の専門家がいると確信しています。彼らは、おそらく彼ら自身の経験によって検証された他の提案を思い付くでしょう。
私が言えることはこれだけです-ショートカットはありません。
ではごきげんよう。
ここにはたくさんの情報があり、率直に言うとTL; DRです。システムを設計する方法を学ぶときに人々が間違っていると思う主なことが1つあります。彼らは、作業が行われる順序でそれについて考えようとします。代わりに、逆方向に作業する必要があります。つまり、設計/アーキテクチャの主な目標は、最終結果がどうあるべきかを決定することです。
類推として、家の建築を考えてみましょう。建築家は、「この家にはいくつの窓が必要ですか？」、「最初のレンガはどこに置くべきですか？」などの質問を自分自身で始めることから始めません。これらの実装の詳細は設計ではなく、設計から派生しています。建築はビジョン、おそらく完成した家がどのように見えるかのスケッチから始まります。一戸建てですか、それともデュプレックスですか？それは豪華な家ですか、それとも手頃な価格の家ですか？同様に、変数がプライベートかどうか、クラスを分割するかどうかは、アーキテクチャとはほとんど関係がありません。
まず、デザインの目標を理解することから始めます。たとえば、これは1回限りのソリューションですか？それは何十年にもわたって拡張され、改訂され、維持されますか？それに対する答えは非常に異なるデザインを示し、それがアーキテクチャのポイントです。何をする必要があるかを理解すると、設計の詳細が自然に従います。これらの詳細が明白または簡単であるというわけではありませんが、これらの選択が基づいているのは高レベルの計画です。
ある種の書き込み-コンパイル-テストループを取得する前に、ソフトウェアの構築にどれだけの時間を費やすべきかを判断する方法は、非常に簡単です。頭に収まるだけの十分な情報があり、それ以上はありません。あなたが取り組んでいるプロジェクトがより厳密な方法論を要求しない限り。どちらの場合も、初心者としては、おそらくアーキテクチャ文書を書くべきではなく、読むべきです。
物事の命名に関しては、私にとっては「書く」ことの一部ですが、間違いなくプログラミングの非常に重要な部分です。物事の命名方法について一生懸命考え、名前の範囲が広いほど、一生懸命考えることを躊躇しないでください。
適切な名前、適切なアーキテクチャ、適切なモジュール性、および適切な抽象化を見つけることは、間違いを犯すことによって得られる経験の一部です。何年もの間、同じことを5回ほど行うプログラムを作成してきましたが、コードは毎回非常に異なっていました。過去の反復ごとに、より良い設計のヒントが得られたからです。