8

私が取り組んでいるプロジェクトは、メインの C# ファイルで 4200 行に達したところです。これにより、IntelliSense の応答に数秒 (場合によっては最大 6 秒程度) かかり、その間に Visual Studio がロックアップします。他の人がどのようにファイルを分割しているか、コンセンサスがあるかどうかが気になります。

いくつかのガイドを探してみたところ、Google の C++ ガイドが見つかりましたが、関数のサイズやファイル サイズなどのセマンティクスについては何もわかりませんでした。たぶんそこにある - 私はしばらくそれを見ていなかった.

では、どのようにファイルを分割しますか? メソッドが提供する機能ごとにメソッドをグループ化していますか? タイプ別 (イベント ハンドラー、プライベート/パブリック)? また、機能を分割するサイズ制限はどれくらいですか?

明確にするために、問題のアプリケーションはデータを処理するため、そのインターフェースは巨大なグリッドであり、すべてがグリッドを中心に展開します。管理用のダイアログフォームがいくつかありますが、それはすべてデータに関するものです。これが非常に大きい理由は、多くのエラー チェック、イベント処理、およびグリッドが各行にさらに 3 つのグリッドを持つマスター/詳細として設定されているためです (ただし、これらのロードはマスター行に展開されます)。これが、私が何を考えているのかを明確にするのに役立つことを願っています。

4

14 に答える 14

5

マーティン・ファウラーの本「リファクタリング」は、このための良い出発点になると思います。「コードの臭い」を特定する方法と、これらの「臭い」を修正するためにコードをリファクタリングする方法について説明します。自然な結果（それは主な目標ではありませんが）は、より小さく、より保守しやすいクラスになってしまうことです。

編集

あなたの編集に照らして、私は常に、バックエンドコードの優れたコーディング手法はプレゼンテーション層でも同じであると主張してきました。UIリファクタリングで検討するのに非常に役立つパターンには、コマンド、戦略、仕様、および状態があります。

簡単に言うと、ビューには、イベントを処理して値を割り当てるためのコードのみを含める必要があります。すべてのロジックは別のクラスに分離する必要があります。これを行うと、リファクタリングできる場所がより明確になることがわかります。グリッドを使用すると、プレゼンテーションの状態をプレゼンテーションロジックとビューの間で簡単に分割できるため、これが少し難しくなりますが、一部の作業では、間接参照を使用して、これによって引き起こされる問題を最小限に抑えることができます。

于 2009-03-03T22:50:07.097 に答える
3

厳格な規則はありませんが、単一の大きな関数よりも短い関数の方が優れており、1 つの大きなクラスよりも小さなクラスが多いほど優れているという一般的な合意があります。

関数が 40 行を超える場合は、それを分割する方法を検討する必要があります。特にネストされたループに注目してください。これはわかりにくく、わかりやすい名前の関数呼び出しに変換しやすいことがよくあります。

プレゼンテーションとロジックを混在させるなど、クラスが複数のことをしていると感じた場合は、クラスを分割します。クラスが 1 つのことを行う限り、大きなクラスは大きなメソッドほど問題にはなりません。

私が見たスタイル ガイドのコンセンサスは、コンストラクターとパブリック メソッドを先頭に、アクセスごとにメソッドをグループ化することです。一貫性のあるものはすべて素晴らしいです。

対処している問題を本当に理解するには、C# スタイルとリファクタリングについてよく読んでください。

Refactoringは、コードを書き直して動作を維持しながらコードをより明確で扱いやすくするためのヒントが記載された優れた本です。

Elements of C# Styleは優れたデッド ツリー C# スタイル ガイドです。このブログ投稿には、優れたオンライン スタイル ガイドへのリンクが多数含まれています。

最後に、FxCopとStyleCopの使用を検討してください。これらはあなたが尋ねた質問には役立ちませんが、コードの他のスタイル上の問題を検出できます。つま先を水に浸したのだから、飛び込んでもいい。

それはたくさんありますが、味、スタイル、明快さを開発することは、良い開発者と悪い開発者の大きな違いです.

于 2009-03-03T22:57:57.237 に答える
1

さて、私はあなたが遅いロード時間よりも手元に大きな問題を抱えているかもしれないと言うことを恐れています。密結合のコードと保守性/可読性の問題にぶつかります。

クラスファイルを小さなファイルに分割するのには非常に理由があります（ファイルを別のプロジェクト/アセンブリに移動するのにも同様に理由があります）。

あなたのクラスが達成することになっている目的について考えてください。各ファイルには、実際には1つの目的しかありません。たとえば、「買い物かごのロジックを含む」など、目標が一般化されすぎている場合は、間違った方向に進んでいます。

また、前述のように、「メインC＃ファイル」という用語は、非常に手続き的な考え方を持っていることを示しています。私のアドバイスは、立ち止まって、一歩下がって、次のトピックのいくつかについて簡単に読んでもらうことです。

  • 一般的なOOPの原則
  • ドメイン駆動設計
  • ユニットテスト
  • IoCコンテナ

あなたの検索で頑張ってください。

于 2009-03-03T22:48:30.253 に答える
1

変化する小さなものを探し、時間をかけてゆっくりとそれぞれを変化させることができます。

  • すべてのメソッドはそのクラスでのみ使用されていますか? ヘルパー/ユーティリティ クラスに移動できる、検証、文字列操作などのサポート メソッドを探します。

  • #region セクションを使用していますか? #region 内の関連するメソッドの論理的なグループ化は、多くの場合、個別のクラスに分割されるのに役立ちます。

  • クラスはフォームですか？フォーム コントロールまたはフォーム コントロールのグループにユーザー コントロールを使用することを検討してください。

多くの開発者が全体的な設計を考慮せずに迅速な修正/新機能を行っているため、大きなクラスが時間の経過とともに進化することがあります。他の人がここで提供している設計理論のリンクのいくつかを再検討し、コード レビューや設計をレビューするためのチーム ワークショップなど、これらを実施するための継続的なサポートを検討してください。

于 2009-03-04T01:07:01.170 に答える
0

Visual Studio 2008 の Intellisense パーサーは、2005 のものよりもかなり高速であるように思われます (彼らが特にこの分野で多くの作業を行ったことは知っています)。 Visual Studio 2008 は、差し迫ったパフォーマンスの問題を解決する場合があります。私はそれを使用して、10万行以上のLinq to SQLファイルを問題なく開きました。

于 2009-03-04T02:55:49.237 に答える