.NET を使い始めて以来、ヘルパー クラスまたは部分クラスを作成して、コードを配置し、独自の小さなコンテナーなどに格納するようにしています。
私が知りたいのは、可能な限りクリーンで洗練されたコードを作成するためのベスト プラクティスです。
明らかにきれいなコードは主観的なものですが、ポリモーフィズム、継承、インターフェイス、クラスなどの (使用方法ではなく) いつ使用するか、およびクラスをより適切に設計する方法 (単に「 DatabaseHelper」、コードのこの悪い習慣は wiki のにおいがすると考える人もいました)。
この種の意思決定に役立つリソースはありますか?
私は CS やソフトウェア エンジニアリングのコースを開始したことすらなく、実際の教育リソースはかなり限られていることを心に留めておいてください。
私にとって本当に目を見張るものは、 Refactoring: Improving the Design of Existing Code :
適切なトレーニングを受ければ、熟練したシステム設計者は、悪い設計を取り上げて、適切に設計された堅牢なコードに作り直すことができます。この本では、Martin Fowler が、リファクタリングの機会が一般的に見られる場所と、悪いデザインを良いデザインに作り直す方法を示しています。
コードを効率的かつ体系的にリファクタリングするのに役立ちました。また、他の開発者との話し合いで、holy code変更が必要になったときに大いに役立ちました...
Jeff Atwood が、リファクタリングとコードの匂いに関する素敵なブログ投稿を作成しました。ぜひチェックしてみてください。
.NET でコードをリファクタリングすると、理解するのに時間がかかります。リファクタリングを効果的かつ無慈悲に行うには、オブジェクト指向の設計原則(または設計技法) をいくつか知っておく必要があります。
つまり、コードの臭いを取り除き、変更を容易にするためにコードをリファクタリングします。また、無理をしないでください。
これはClean Codeという本のスラッシュドットに関するレビューです。
本は明らかに少し乾いているようですが、とても良いです。
Martin Fowler のコメントとRefactoringに関する本をチェックしてください。
ドメイン駆動設計をお勧めします。YAGNI と AlwaysRefactor の原則は単純化されていると思います。この問題に関する古くからの質問は、「if(someArgument == someValue)」を関数にリファクタリングするか、インラインのままにするかです。
はいまたはいいえの答えはありません。DDD は、テストがビジネス ルールを表している場合は、リファクタリングすることをお勧めします。リファクタリングは再利用だけではなく、意図を明確にすることです。
『レガシー コードを効果的に扱う』は、このテーマに関して私が読んだ中で最高の本の 1 つです。
本のタイトルから遠ざかってはいけません - リファクタリングを正式な概念として扱うのではなく (それはその場所にあります)、この本には、「なぜ私はそれを考えなかったのか」という単純なヒントがたくさんあります。「クラスを通過し、そのクラスに直接関連付けられていないメソッドを削除して、別のクラスに配置する」などです。
たとえば、グリッドと、そのグリッドのレイアウトをファイルに保存するためのコードがあります。おそらく、レイアウト永続化コードを別のクラスに安全に移動できます。
http://www.refactoring.com/にリファクタリング専用のWebページがあります。リファクタリング関連の問題を議論するためのメーリングリストだけでなく、リファクタリングコードのトピックに関するその他のリソースへの多くの参照を備えています。
最後になりましたが、Martin Fowlerによる（非常に推奨される）リファクタリングの本に書かれているものをはるかに超えた、利用可能なリファクタリングの大きな（そしてまだ成長している）カタログがあります。
Code Complete のコピーを入手したところ、これに関するセクションがあることがわかりました。
受け入れられた回答の本をまだ読んでいますが、Code Complete から学んだことは、クラスの設計に関する私の考え方を劇的に改善しました。
今日まで、私は ADT (抽象データ型) が何であるかを知りませんでしたが、今ではカプセル化に準拠したクラスを開発する方法を知っています。
