オブジェクト指向設計で何をする必要があるかを実際に調べる方法は？

最初の免責事項：この質問がこのウェブサイトに適合するかどうかはわかりませんが、私だけでなく、初心者である他の人にとっても関連する質問であることに変わりはありません。ここに収まるように質問を改善できる場合は、intコメントを指摘してください。それが合わない場合は、私にも知らせてください。可能であれば、これに関する良いフォーラムが見つからなかったので、これについて議論できる場所を教えてください。

私はPHPを勉強した2009年にプログラミングを学びました。2012年の後半に、C＃と.NETに移行しました。とにかく、コーディングは問題ではなく、アルゴリズムを書き留めることは私の問題ではありません。私の実際の問題は、要件を達成するために何をコーディングする必要があるか、どこでコーディングする必要があるかを知ることです。

Web上で利用できるそこにほとんどのコースは対処方法ここでは私のポイントではないなど、いくつかのAPIセットを使用する方法、特定の言語でコードを書く方法を- 。

ここ数年、オブジェクト指向の分析と設計、設計パターン、ドメイン駆動設計など、たくさんのことを読みました。たとえば、SOLIDの原則、ドメインエキスパートの関与の必要性、ユビキタス言語の開発など、DDDの主要なアイデアのいくつかを理解しています。少なくとも理にかなった理論的背景があると思います。

しかし、それが練習になると、私は災害だと感じます。しばらく前に、私はすでに他の誰かによって開発されていた金融システムの開発を続ける必要がありました。それは、C＃とWinFormsで開発されたそのような「古いシステム」です。実際のドメインの複雑さ、多くのビジネスルールなどを含むプロジェクトを選んだのは初めてでした。

ほとんどの場合、要件を受け取ったとき、「一体どうやってこれを行うことができるのか」と思います。-どうすればよいのかを理解するために、要件の作業を開始する方法すらわからない。私が信じている主な混乱は、私がコーディングしなければならないもの、クラス、インターフェース、そして各ロジックがどこに行くのか、各クラスがどのクラスにあるべきなのかです。問題は、どこから始めればいいかわからないことです。

ほとんどの場合、非常に多くの考えでいくつかのアイデアになりますが、私のアイデアが正しいかどうかを判断する方法がわかりません。

推奨されたソフトウェアアーキテクチャとオブジェクト指向に関する多くのことを読んだと言ったので、これは理論の欠如ではないと思いますが、実際には何をしなければならないかを特定するのにはあまり役立ちませんでした。

それでは、どうすればオブジェクト指向設計を実際に 行うことができますか？私が学びたいのは、与えられた要件は、何をすべきか、各コードがどこに属しているかを見つけるプロセスでそれらに取り組む方法を知っていることです。自分の考えが正しいかどうかを判断する方法を学ぶにはどうすればよいですか？

ここで答えとしてこれを完全に説明することは不可能だと思います。しかし、私が探しているのは、サイトのスタイルに応じて、単に概要を示し、アイデアを拡大し、これらのことを実際に学習するために使用できる参照（書籍、オンラインコースなど）を示す回答です。

それでは、どうすればオブジェクト指向設計を実際に行うことができますか？私が学びたいのは、与えられた要件は、何をする必要があり、各コードがどこに属しているかを見つけるプロセスでそれらに取り組む方法を知っていることです。自分の考えが正しいかどうかを判断する方法を学ぶにはどうすればよいですか？

まず第一に、オブジェクト指向設計を正しいと考えるのをやめます。それは英語を正しいと考えるようなものです。

オブジェクト指向のパラダイムは正しくありません。いくつかの長所と短所があります。理想的です。それだけではありません。何もないよりはましですが、すべてではありません。

私は何十年もコーディングを続けてきました。アイデアが存在する限り、私はこのようなことを研究してきました。私はまだそれが何を意味するのかを学んでいます。専門家はまだそれが何を意味するかを学んでいます。私たちのフィールド全体は100年未満です。

したがって、要件の山を取り、それらを満足させるコードを見つけたが、あなたが書いたコードはあなただけではない悲劇的な混乱のように感じます。作業コードは、優れたコードの第一歩です。動作するだけでなく、他の人が簡単に読んで理解できるコード。要件が変更されたときに迅速に適応できるコード。座って「うわー、それはとても簡単だ」と言いたくなるコード。

問題は、そのすべてを行うための報酬を得ていないことです。私たちはプロだからです。期限が常にあるため、上司が見ていなければ、すべてを行う必要があります。しかし、私たちは5年後に戻ってきて、初心者に「ああ、そうです、私はそれを書きました。それでも動作しますか？クール」と言いたいです。

どうやってそこに行きますか？練習。信仰に関するいかなる設計思想も受け入れないでください。イベント駆動型設計がこの設計をどのように簡素化するかについて誰かが黙っていないでしょうか？彼らが正しいかどうかわからない？オブザーバーパターンを使用する自宅で独自のおもちゃプロジェクトを構築します。それで混乱。役に立たないものを見つけてください。

読んだ。質問。テスト。繰り返す。

人生の80％でそれをやってきたという点に達すると、私と同じくらい混乱するでしょう。

ほとんどの場合、要件を受け取ったとき、「一体どうやってこれを行うことができるのか」と思います。-どうすればよいのかを理解するために、要件の作業を開始する方法すらわからない。私が信じている主な混乱は、私がコーディングしなければならないもの、クラス、インターフェース、そして各ロジックがどこに行くのか、各クラスがどのクラスにあるべきなのかです。問題は、どこから始めればいいかわからないことです。

以前も同じように感じていました。それから、リファクタリングの喜びを発見しました。コーディング中にデザインを適応させてください。事前にすべてを紙の上で解決しようとするのは難しい方法です。間違っていると証明できるコードを書き、間違っていることを証明し、修正します。

ソフトウェア開発は、すべての受け入れ基準を満たしながら、時間通りに、予算内で動作するソフトウェアを提供することになります。あなたがそれをなんとかしたと仮定すると、コードまたはその構造の知覚品質は二次的な関心事です。

もちろん、問題は、新しいグリーンフィールドコードを書くことは、レガシーコードを維持するよりもはるかに安価で簡単になる傾向があるため、コードの品質やアーキテクチャにこだわるのではなく、実際の問題が保守性であることを思い出してください。

通常、コードの変更に伴うコスト、時間、リスクが比例して低く、バグの修正や要件の変更の実装が依然として費用効果が高く、それらの変更を実装することで「死のスパイラル」が持続しない場合、コードは保守可能と見なされます「コードエントロピーの。

逆に、何かを壊したり、何も壊れないようにするために過度の時間/お金を費やすなどの深刻なリスクなしに自信を持って変更またはリファクタリングできない場合、コードはメンテナンス不可能と見なされます。変更を行うことの利点と比較して不釣り合いに高い（つまり、雇用主または顧客は、新機能の追加、バグの修正など、お金を失うことはありません）

破壊的な変更から身を守るために十分な対策を講じていれば、最も悪魔的なスパゲッティの混乱でも維持できる可能性があることに注意してください（そのようなケースはまれです）。スパゲッティの混乱の問題は、破壊的な変更からスパゲッティを保護することは、非常に高価で非効率になる傾向があることです-特に、過去に遡ってやっている場合。

おそらく、メンテナンス可能なコードを作成したことを保証する最も信頼できる方法は、（合理的に可能な場合）同時に適切な自動テストのスイートを作成することです（利用可能な他の静的分析ツールも最大限に活用します）。

リファクタリングを可能にするために十分な自動テストを行うために、TDD / BDDなどの厳格な開発方法論に従う必要は特にありません。将来の偶発的な破壊的な変更からコードを保護するのに十分なだけです。

コードが自動化されたテストでカバーされている場合、それらのテストでカバーされていることを知っているので、設計と構造についてリラックスできます。後日に積極的にリファクタリングすることも、破棄してやり直すこともできます。

これは、簡単にテスト可能なコードをどのように書くかという疑問を招きます。これは通常、SOLID原則に従うための主な議論です。実際、SOLID原則に準拠するコードの特徴は、ユニットテストを記述するのに簡単で時間/コストが効果的であることです。

もちろん、ユニットテストを書く時間がない場合もあります。ただし、「このための自動テストを作成するにはどうすればよいですか？」という質問を念頭に置いてすべてのコードを作成した場合 （実際にこれらのテストを実装しなかったとしても）、おそらく合理的に保守可能な設計を見つけることができたでしょう。