特定のレベルの複雑さに達すると、大規模なプロジェクトに絶えず圧倒されます。プロジェクトの特定のポイントに達すると、進行が遅くなり、絶えずステップをたどり、あらゆる種類の混乱を整理します。

私のこの弱さのために、リファクタリングが本当に上手になりました。そして、私は常にオブジェクトをより小さく管理しやすいものに分解しようとしています。この弱点のために、物事を適切に設計することにあまりにも注意を払うことになりました。

問題を小さな問題に分解できれば、スムーズに達成できると思います。頭に浮かぶ戦略の1つは、テスト駆動開発です。他に何ができますか？

コードについて考えるのをやめる

レイヤー、機能、モジュール、サービス、その他の高レベルの抽象化について考え始める

あなたが低すぎるレベルで考えているので、あなたは圧倒されています

複雑なものを単純にすることは簡単です。それが逆だと思うのを待ってください。

誰もがこれに苦労していますが、極端な効果をもたらす簡単な解決策はありません。

あなたはあなたの質問にこれをリストしなかったので、私の提案は次のようになるでしょう：

以下を介して機能的凝集に焦点を当てる：

単一責任の原則では、すべてのオブジェクトに単一の責任があり、その責任はクラスによって完全にカプセル化される必要があると規定されています。すべてのサービスは、その責任と厳密に連携する必要があります。

あなたがいる場合、それをGoogleに最初のページの結果のうち次の2つの偉大なリソースを見つけることができます：

• Robert C. Martinの「単一責任原則」（2002年2月）：この原則は、さまざまなクラスでさまざまな理由で変化するものを配置する必要性について説明しています。
• 「カーリーの法則：ワンシングシング」ジェフアトウッド（2007年3月）：単一の責任原則では、クラスには変更する理由が1つだけである必要があると述べています。

コンピューターサイエンスにおける凝集とは何ですか？

凝集度とは、単一のモジュールの責任がどれほど強く関連しているか、または集中しているかの尺度です。オブジェクト指向プログラミングに適用される場合、特定のクラスを提供するメソッドが多くの側面で類似する傾向がある場合、そのクラスは高い凝集度を持っていると言われます。凝集度の高いシステムでは、コードの可読性と再利用の可能性が高まり、複雑さは管理しやすくなります。

次の場合、凝集度は低下します。-クラスに埋め込まれ、そのメソッドを介してアクセスされる機能に共通点はほとんどありません。-メソッドは、多くの場合さまざまなアクティビティを実行します。多くの場合、粗くまたは無関係なデータセットを使用します。

低凝集度（または「弱凝集度」）の欠点は次のとおりです。- モジュールを理解するのが難しくなります。-ドメインの論理的な変更が複数のモジュールに影響し、1つのモジュールの変更が関連モジュールの変更を必要とするため、システムの保守が難しくなります。-ほとんどのアプリケーションはモジュールによって提供される操作のランダムなセットを必要としないため、モジュールの再利用の難易度が増加しました。

ご質問がある場合は、お知らせください。

フィーチャを可能な限り最小のアイテムに分解します。たとえば、フォーム上の単一のフィールド。最もリスクが高い、または優先度の高いものを選択し、大きなプロジェクトではなく、単純なバグ修正のように前進します。後からリファクタリングを行うことになるのは事実ですが、少なくとも前進します。

私の経験から、TDDについてのコメントで自分の質問に答えました。私にとって、私はしばしばあなたと同じように感じました。初期の速い成功は、システムが特定のサイズに達するとすぐに小さな詳細に行き詰まることになりました。TDDを使用すると、システムの各部分を小さな塊として扱うことができ、システムの残りの部分がそのまま残っているか、または機能し続ける必要があることがわかったので役立ちました。また、TDDを使用すると、システムが明確に小さなチャンクに分割され、独立してテストできるようになります。

一部の人々は、モジュール式で簡単に理解できるプログラムの設計に長けていますが、大部分のプログラマーは多少なりともこの機能を欠いています。おそらく多くの経験を除いて、最初のタイプのプログラマーの1人を2番目のタイプに変えることができる本、手順、または実践を知っています。しかし、私もそれについて確信がありません。

一番下の行は、ほとんどのプログラマーが平凡を超えるのに苦労し、何人かは大丈夫です（私は自分自身とおそらくIB業界のプロのプログラマーの50％を配置します）、そして非常に小さな少数派が優れているでしょう。私の長いキャリアの中で、これらの素晴らしいキャリアの1つに出会ったことは一度もないと言っておくべきです:-)

多くの人がソリューションをオーバーエンジニアリングしようとしています。彼らは「アダムとイブ」のアプローチを採用しますが、ほんの少し実用的なアプローチが物事を大幅に簡素化します。

特殊なクラスは悪ではなく、健全なソフトウェア設計の自然な結果です。

私の意見では、多くのプログラマーはこれを理解できず、このことを完全に明確にしている本はありません。

確かに役立つもう1つのことは、TDDです。これにより、実際にクラスを使用する「方法」を理解でき、多くの場合、1日の早い段階で最終的な問題/制限が示されるため、1日を節約できます。

最後に、私があなただったら探しているもう一つの非常に重要なことはデザインパターンです。デザインパターンは、あなたや私よりも賢い人がプログラミングの問題を解決する方法です。パターンの背後にある考え方は、何を推測するのでしょうか？クックブックとして使用するのではなく、単にそこにバタバタするレシピではなく、思慮深く、アプリケーションドメインを何よりもまず理解するということです。

パターンを賢く使用すると、管理する必要がある詳細の量が大幅に削減されます。

まさにあなたのニーズに合わせて設計された優れたデザインパターンライブラリは、非常に貴重です。コンテキストに物事を置くための非常に簡単な例を見てみましょう：

ボタンが押されたときに、他のフォームが自分自身を更新する必要があるフォームがあるとします。これは典型的な「オブザーバー」パターンです。サブジェクトと複数のオブザーバーがいて、それらをサブジェクトに登録します。なぜインターフェイスを実装する必要があるのですか？メソッドを追加することもできますが、オブザーバー用のインターフェイスとサブジェクト用の汎用リストを使用することもできます。これで両方の長所が得られました。オブザーバーの独立性と、話題に関する曖昧なものはありません。

それがあなたにとって意味があることを願っています！

アンドレア

開発の速度と読みやすさの問題は、抽象化の必要性を見落とすときに発生する可能性があります。私が取り組んできたいくつかの大規模なコードベースでは、最も一般的な敵は、コードが肥大化する非常に類似した機能を備えた膨大な量の特殊なクラスでした。一歩下がって、要件をアプリケーションの一部としてではなく全体として理解すると、多くの抽象化が思い浮かぶでしょう。

私を助けてくれたいくつかの簡単なステップ

• 類似性アナライザー（Simianなど）を使用して、コードベース全体で重複するコードブロックを見つけます。コードの重複は、抽象化が少ないことを意味します。
• クラスとメソッドのサイズを監視します。大きなクラスとメソッドは、神になるサービスやコントローラーがほとんどないことを意味します。
• ユニット/統合テストを必須にし、リファクタリングへの自信を与え、仕様としても機能します。
• 使用する技術/ビジネス/ドメインの用語がクラス名に反映されているかどうかを理解するための、ビジネスとの隔週振り返り。これは、単純なセットやリストとして表すのではなく、ファーストクラスコレクションの名前を理解して取得するのに役立ちます。私たちが考えもしなかったいくつかの抽象化は、ビジネスマンと座ったときにも現れます。