コーディングガイド：大きなソースファイルをどのように分割しますか？

https://stackoverflow.com/questions/608530

03-07-2019
|

質問

私が取り組んでいるプロジェクトは、メインC＃ファイルで4200行に達しました。これにより、IntelliSenseが応答するのに数秒（場合によっては6秒程度）かかり、その間にVisual Studioがロックします。他の全員がどのようにファイルを分割し、コンセンサスがあるかどうか疑問に思っています。

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

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

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

解決

問題は、使用する用語「＆quot;メインC＃ファイル＆quot;」で要約されていると思います。

main（メソッドmain（）のように）を意味する場合を除き、その概念には場所がありません。

キャッチオールユーティリティクラスまたは他の一般的なメソッドがある場合、それらを同様の機能部分に分割する必要があります。

通常、私のファイルはクラスの1対1のマッピングです。

時々、非常に関連のあるクラスが同じファイルにあります。

ファイルが大きすぎる場合は、クラスが大きすぎて一般的すぎることを示しています。

メソッドを半画面以下に維持しようとしています。（最初から記述するコードの場合、通常は12行以下ですが、最近は他の開発者の既存のコードで作業しており、100行の関数をリファクタリングする必要があります...）

画面の場合もありますが、非常に大きくなっています。

編集：

関数に関するサイズ制限の質問に対処するために-私にとっては、サイズについてはそれほど問題ではありませんが（問題を示す良い指標ですが）、1つのことだけを行い、それぞれをシンプルに保つことを重視します。

他のヒント

クラシックブックの＆quot; 構造化プログラミング＆quot;ダイクストラはかつて、「私たちの多くのことができないことについて」というタイトルのセクションを書きました。彼のポイントはシンプルでした。人間はあまり賢くない。一度に思いつくのは、いくつかの概念だけです。

クラスとメソッドを小さく保つことは非常に重要です。メソッドが数十行以上になったら、分割する必要があります。クラスが数百行を超えると、クラスは分割されます。これは、コードを適切に整理して管理しやすくする唯一の方法です。私は40年近くプログラミングを行ってきましたが、毎年このように「小さな」という言葉がどれほど重要かを実感しています。ソフトウェアを書くときです。

これをどのようにどのように行うかについては、これは非常に大きなトピックであり、何度も書かれています。依存関係の管理、情報の隠蔽、および一般的なオブジェクト指向の設計がすべてです。ここに読書リストがあります。

タイプを分割するのが自然なところでタイプを分割します-ただし、実行しすぎているタイプには注意してください。約500行（JavaまたはC＃）で心配になります。約1000行で、タイプを分割するかどうかを一生懸命に調べ始めます...しかし、時には分割できない/すべきでない場合があります。

メソッドに関して：一度に画面上でメソッド全体を見ることができないとき、私はそれが好きではありません。明らかにそれはモニターのサイズなどに依存しますが、それは合理的な経験則です。私はそれらがより短いことを好む。繰り返しますが、例外がいくつかあります。特に、自然に一緒にカプセル化されたくないローカル変数がたくさんある場合は、いくつかのロジックを解くのは非常に困難です。

System.Linq.Enumerable ですが、そのような場合、型を論理グループに分割できる場合、部分クラスが役立ちます（ Enumerable の場合、集約によるグループ化/設定操作/フィルタリングなどは自然に思えます）。しかし、私の経験ではそのようなケースはまれです。

Martin Fowlerの本リファクタリングこのための良い出発点になると思います。「コードのにおい」を識別する方法について説明します。これらの「臭い」を修正するためにコードをリファクタリングする方法。自然な結果は（主な目的ではありませんが）、より保守しやすいクラスになります。

編集

編集の観点から、私は常に、バックエンドコードの優れたコーディングプラクティスはプレゼンテーション層でも同じだと主張してきました。 UIリファクタリングで考慮すべき非常に便利なパターンには、コマンド、戦略、仕様、および状態があります。

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

手続き的にコーディングしないでください。1つのファイルで4,200行になることはありません。

C＃では、いくつかの SOLID に従うことをお勧めしますオブジェクト指向の設計原則。すべてのクラスには、変更する唯一の理由が必要です。メインメソッドは、アプリケーションの開始点を起動するだけです（StructureMapなどを使用している場合は、依存関係注入コンテナーを構成します）。

通常、200行を超えるコードを持つファイルはありません。100未満の場合は、それらを好むでしょう。

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

40行以上の関数は、どのように分割できるかを検討する必要があります。特に、ネストされたループを見てください。これはわかりにくく、わかりやすい名前の関数呼び出しに簡単に変換できます。

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

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

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

は優れた本であり、動作を維持するようにコードを書き直すためのヒントがありますが、コードはより明確で扱いやすいです。

C＃スタイルの要素は優れた枯れ木C＃スタイルガイドであり、このブログ投稿には、優れたオンラインスタイルガイドへのリンクが多数あります。

最後に、 FxCop の使用を検討し、 StyleCop 。これらは、あなたが尋ねた質問には役立ちませんが、コードに関する他の文体的な問題を検出できます。つま先を水に浸したので、飛び込むこともできます。

それはたくさんありますが、良いデベロッパーと悪いデベロッパーの違いは、味、スタイル、明快さを開発することです。

各クラスは、1つの小さなことを実行し、適切に実行する必要があります。クラスはフォームですか？その場合、ビジネスロジックは含まれません。

それは、ユーザーや州のような単一の概念を表しますか？その後、描画、ロード/保存などを行わないでください...

すべてのプログラマーは段階とレベルを通過します。現在のレベルの問題を認識しており、次のレベルに近づく準備ができています。

あなたの言ったことから、現在のレベルは「問題の解決」であり、おそらく手続き型コードを使用しているように思われます。そして、あなたはそれにアプローチする新しい方法をもっと見始める必要があります。

実際にオブジェクト指向設計を行う方法を調べることをお勧めします。聞いたことがあるかもしれませんが、意味をなさない多くの理論があります。使用しない理由は、現在のプログラミング方法には適用されないからです。

Lemmeが適切な投稿を見つけます...これらを確認して開始してください：

how-do-i-break-my-procedural-coding -習慣

are-there-any-rules-for-oop

object-oriented-best-practices-inheritance-v -composition-v-interfaces

優れたオブジェクト指向デザインの本を紹介する投稿もあります。「リファクタリング」本はおそらくあなたが始めることができる最高の場所の一つです。

あなたは今、良い時点にいますが、あなたはどこまで行かなければならないのか信じられません。近い将来このようなものが最高のプログラミング「学習体験」の一部になるので、あなたがそれに興奮していることを願っています。

がんばって。

変更する小さなものを探して、時間の経過とともにゆっくりと変更することができます。

すべてのメソッドはそのクラスでのみ使用されていますか？ヘルパークラスやユーティリティクラスに移動できる検証、文字列操作などのサポートメソッドを探します。
#regionセクションを使用していますか？ #region内の関連メソッドの論理グループは、多くの場合、個別のクラスに分割されるのに役立ちます。
クラスはフォームですか？フォームコントロールまたはフォームコントロールのグループにユーザーコントロールを使用することを検討してください。

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

まあ、遅いロード時間よりも大きな問題があるかもしれないと言うのは怖いです。密結合されたコードと保守性/可読性の問題の問題に遭遇するでしょう。

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

クラスが達成すべき目的を考えてください。各ファイルには、実際には1つの目的のみが必要です。「ショッピングバスケットロジックを含める」など、目標があまりにも一般化されている場合、間違った方向に進んでいます。

また、前述のように、使用する用語：＆quot; Main C＃file＆quot;あなたが非常に手続き的な考え方を持っていることをただ嘆きます。私のアドバイスは、停止し、後退し、次のトピックのいくつかを簡単に読むことです。

一般的なOOPの原則
ドメイン駆動設計
単体テスト
IoC コンテナ

検索の成功をお祈りします。

部分クラスを使用します。基本的に、単一のクラスを複数のファイルに分割できます。

おそらくOPは応答できます：プロジェクトはオブジェクト指向プログラミングを使用していますか？「ファイル」という言葉を使用しているという事実そうでないことを示唆しています。

オブジェクトの向きを理解するまで、重要な方法でコードを改善する見込みはありません。ファイルをまったく分割せずに、耐えられないほど遅くバグが多くなるまで待ってから、それ以上耐えるのではなく、オブジェクト指向を学んでください。

Visual Studio 2008のIntellisenseパーサーは、2005年よりもかなり高速であるようです（この領域で具体的に多くの作業を行ったことがわかっています）。前述のとおり、Visual Studio 2008はパフォーマンスの問題をすぐに解決する場合があります。これを使用して、100K以上のLinq to SQLファイルを問題なく開くことができました。

各クラス/ファイル/関数/などになるようにコードを分割します。 One Thing＆＃8482;のみを行います。単一責任原則は、機能をクラスに分割するための優れたガイドラインです。

最近、筆者が書いた最大のクラスは約200行の長さで、メソッドのほとんどは1〜10行の長さです。

クラス内にコードの領域がある場合、簡単な方法は、 partial キーワードを使用して、クラスの定義をそのファイルに分割することです。通常、大規模なクラスに対してこれを行います。

私が使用する規則は、ClassName_RegionName.csを持つことです。たとえば、データベース接続のスキーマを管理するクラスを分割し、DatabaseConnectionクラスを呼び出す場合、メインクラスのDatabaseConnection.csというファイルを作成し、スキーマ機能のDatabaseConnection_Schema.csというファイルを作成します。

一部のクラスは大きくする必要があります。それは悪い設計ではありません。それらは実装が重いだけです。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow