スタックオーバーフローのユーザー、
大規模なメソッドを使用して大規模なクラスを作成しないようにするにはどうすればよいですか。締め切りがきついときは、まとめてハックしようとすることになり、リファクタリングが必要な混乱に陥ります。
1 つの方法は、テスト駆動型開発から始めることです。これは、SRP (Single Responsibility Principle) だけでなく、優れたクラス設計にも役立ちます。
また、開発者がコントロールをダブルクリックし、発生するイベント メソッドで行ごとに入力しているのも見られます。
助言がありますか？
それは何よりもあなたの内部プロセスに依存していると思います。
私の会社では、ピアレビューを実践しており、コミットされるすべてのコードは、コードを説明する必要がある別の開発者によって「仲間」にならなければなりません。
時間の制約も問題の 1 つですが、非常に長いクラスを含むコードをレビューすると、チェックインに同意しません。
最初は慣れるのが大変ですが、最終的には誰にとっても良いものです。
また、優れたクラス設計の擁護者であり、喜んで例を挙げてくれる上級開発者がいることは、非常に役立ちます。
最後に、私たちは自分たちの仕事を同僚に披露するための「ショー アンド テル」セッションをコーディングすることがよくあります。
ResharperやExtractMethodコマンドなどのツールを使用します。
Long classes is one bad code smell of many possible.
Remedying overly large classes by creating lots of small ones may create its own problems. New engineers on your project may find it difficult to follow the flow of the code to work out what happens where. One artifact of this problem can be very tall call stacks, execution nesting through many small classes.
別の提案は、求められたことだけを行うことです。「もしも」ゲームをプレイして、ソリューションを過剰に設計しようとしないでください。これには、「シンプルに、愚かに」という考え方があります。
私たちは Java と Maven ショップであり、その中の 1 つです... 私たちが使用するフォレンジック メソッドは、優れた FindBugs、PMD、および javancss プラグインであると言えます。すべてがメソッド内の過度の長さについて警告を出し、循環的複雑度の計算は非常に目を見張るものがあります。
SRP に違反することが多い大規模なクラスを回避するための唯一の最も重要なステップは、単純な依存性注入フレームワークを使用することでした。これにより、物事を結び付ける方法についてあまり考えることから解放されました。コンストラクター注入のみを使用して、デザインをサイクルから解放します。Resharper のようなツールは、コンストラクター引数からフィールドを初期化するのに役立ちます。この組み合わせにより、新しいクラスを作成して接続するためのオーバーヘッドがほぼゼロになり、動作をより詳細に構造化することが暗黙のうちに奨励されます。
これはすべて、データが動作から分離されている場合に最適に機能し、依存関係グラフの下方向に流れる通信を切り離すために使用できるイベントなどの構造が言語でサポートされている場合に最適です。
自動ビルドでいくつかの静的コード分析ツールを使用し、いくつかのルールを作成/構成/使用して、たとえば、誰かがそれを破ったときに正当化を書かなければならない..