圧倒的なコードを扱いやすいチャンクに分解する最良の方法は？
大規模なプロジェクトが特定のレベルの複雑さに達すると、私は絶えず圧倒されています。プロジェクトの特定のポイントに到達すると、進行が遅くなり、常に自分のステップをたどり、あらゆる種類の混乱を整理していることに気づきます。
私のこの弱点のため、私はリファクタリングが本当に得意です。そして、私は常に自分のオブジェクトをより小さく、より扱いやすいものに分解しようとします。この弱点も、私が物事を適切に設計することにあまりにも多くの注意を払う原因になったのかもしれません。
問題をもっと小さな問題に分解できれば、スムーズに達成できると思います。頭に浮かぶ1つの戦略は、テスト駆動開発です。他に何ができますか？
コードについて考えるのをやめる
レイヤー、機能、モジュール、サービス、およびその他の上位レベルの抽象化について考え始める
低すぎるレベルで考えているので、あなたは圧倒されています
複雑なものをシンプルにするのは簡単です;それが逆だと思って待ってください。
誰もがこれに苦労していますが、非常に効果的な簡単な解決策はありません。
これを質問に記載しなかったので、私の提案は次のとおりです。
機能的凝集 に焦点を当てます：
単一の責任の原則 は、すべてのオブジェクトが単一の責任を持つべきであり、その責任はクラスによって完全にカプセル化されるべきであると述べています。そのすべてのサービスは、その責任と密接に連携する必要があります。
Google it 最初のページの結果の中に2つの優れたリソースがあります。
- " Single Responsibility Principle " by Robert C. Martin（Feb/2002）：この原則は、異なる理由で変化するものを異なるクラスに配置する必要性について説明します。
- " Curly's Law：Do One Thing " by Jeff Atwood（Mar/2007）：Single Responsibility Principleによると、クラスには変更すべき理由が1つだけ必要です。
コンピュータサイエンスの結束とは何ですか？
凝集度 は、単一モジュールの責任がどの程度強く関連しているか、または焦点が合っているかの尺度です。オブジェクト指向プログラミングに適用される場合、特定のクラスを提供するメソッドが多くの点で類似している傾向がある場合、そのクラスは凝集度が高いと言われます。非常にまとまりのあるシステムでは、コードの可読性と再利用の可能性が高まると同時に、複雑さが管理可能に保たれます。
以下の場合、凝集度が低下します：-メソッドを介してアクセスされるクラスに埋め込まれた機能には、ほとんど共通点がありません。 -多くの場合、メソッドはさまざまなアクティビティを実行します。多くの場合、大まかなデータまたは関連のないデータセットを使用します。
凝集力が低い（または「凝集力が弱い」）場合の欠点は次のとおりです。-モジュールの理解が難しくなります。 -ドメインの論理的な変更が複数のモジュールに影響し、1つのモジュールの変更には関連モジュールの変更が必要になるため、システムの保守の難しさが増します。 -ほとんどのアプリケーションは、モジュールによって提供されるランダムな操作のセットを必要としないため、モジュールの再利用の難しさが増しました。
ご不明な点がございましたら、お気軽にお問い合わせください。
機能を最小のアイテムに分解します。たとえば、フォーム上の単一のフィールド。最もリスクの高い、または優先度の高いものを選び、大きなプロジェクトではなく単純なバグ修正であるように進んでください。後で何らかのリファクタリングが行われることは事実ですが、少なくとも前進することになります。
私の経験から、あなたはTDDに関するコメントであなた自身の質問に答えました。私にとってはあなたと同じように感じることが多かったのですが、システムが特定のサイズに達すると、早い段階での成功はすぐに細部に行き詰まりました。私はTDDを使用して、システムの各部分に小さなチャンクとして取り組むことができ、システムの残りの部分はそのままにしておくか、そのままにしておく必要があるので、それが役立つことを発見しました。また、TDDを使用すると、システムを独立してテスト可能な小さなチャンクに明確に分割するのに役立ちます。
モジュール化された、理解しやすいプログラムの設計が得意な人もいますが、大多数のプログラマーはこの機能を多少なりとも欠けています。 lotsの経験を除いて、最初のタイプのプログラマーの1人を2番目のタイプのプログラマーに変えることができる本、手順、または実践については知りません。しかし、それについてはよくわかりません。
肝心な点は、ほとんどのプログラマーは平凡なレベルを上回ろうと奮闘し、一部の人は問題なく成功するでしょう（ここで私と私は（おそらく）IB業界のプロのプログラマーの50％を配置します）。小さな少数派は素晴らしいでしょう。私は長いキャリアの中でこれらの優れたものに会ったことは一度もありません:-)
多くの人がソリューションを過剰設計しようとしていると思います。彼らは、 "Adam＆Eve"のアプローチを採用していますが、少し実用的な方が大幅に単純化されます。
特殊化されたクラスは悪ではありません、それらは健全なソフトウェア設計の自然な帰結です。
私の意見では、多くのプログラマーはこれを理解できておらず、これを完全に明らかにする本を私が知っている本はありません。
確かに役立つもう1つのことはTDDです。これは、実際にクラスを使用する「方法」を理解し、多くの場合、その日の早い段階で最終的な問題/制限を示すため、その日を節約できます。
最後に、私があなただったら探していたもう1つの非常に重要なことは、デザインパターンです。デザインパターンは、あなたや私よりも賢い人々がプログラミングの問題を解決する方法です。パターンの背後にあるアイデアは、何だと思いますか？それらはクックブックとして使用するのではなく、あなたがそこにたたくだけのレシピですが、思慮深く、そして何よりもまずアプリケーションドメインを理解しています。
パターンを賢く使用すると、管理する必要がある詳細の量が大幅に削減されます。
お客様のニーズに合わせて設計された優れたデザインパターンライブラリは、非常に貴重です。状況を把握するための非常に単純な例を見てみましょう。
ボタンが押されたときに他のフォームがそれ自体を更新する必要があるフォームがあるとします。これは典型的な「オブザーバー」パターンです。あなたには主題といくつかのオブザーバーがいて、彼らは彼ら自身を主題に登録します。なぜインターフェースを実装する必要があるのですか？メソッドを追加するか、オブザーバーのインターフェースとサブジェクトの汎用リストを使用することもできます。今、あなたは両方の世界の最高のものを手に入れました：オブザーバーのための独立性と主題についての気まぐれなものはありません.
それがあなたにとって理にかなっていることを願っています！
アンドレア
抽象化の必要性を見落とすと、開発速度と可読性の問題が発生する可能性があります。私が取り組んだ大規模なコードベースのいくつかでは、最も一般的な唯一の敵は、コードを肥大化させる非常に類似した機能を持つ特殊なクラスの膨大な量でした。一歩下がって、アプリケーションの一部としてではなく、全体として要件を理解すると、多くの抽象化が思い浮かぶでしょう。
私を助けてくれたいくつかの簡単なステップ
- 類似性アナライザー（Simianなど）を使用して、コードベース全体で重複するコードブロックを見つけます。重複するコードが多いと、抽象化が少なくなります。
- クラスとメソッドのサイズを監視します。大きなクラスとメソッドは、神になるサービスやコントローラーが少ないことを意味します。
- ユニット/統合テストを必須にし、リファクタリングの信頼を与え、仕様としても機能します。
- ビジネスを隔週で振り返って、彼らが使用する技術/ビジネス/ドメインの用語がクラス名に反映されているかどうかを理解します。これは、単純なセットやリストとして表すのではなく、ファーストクラスコレクションの名前を理解して取得するのに役立ちます。ビジネスの人々と一緒に座ると、私たちが考えもしなかったいくつかの抽象化も表面化します。