少なくともコードを変更すれば、どのコードも何らかの方法で再利用できます。ランダムコード自体はあまり再利用できません。私が何冊かの本を読むと、通常、コードを使用する他の状況も考慮して、コードを明示的に再利用可能にする必要があると書かれています。しかし、特定のコードは全能クラスであってはなりません。
後で変更する必要のない再利用可能なコードが必要です。コードを再利用可能にするにはどうすればよいですか? コードを再利用可能にするための要件は何ですか? 再利用可能なコードに必ず含まれているものと、オプションのものは何ですか?
再利用可能なコードを書くための 10 のヒントを参照してください。
テスト駆動開発アプローチを採用する場合、コードは今後のシナリオに基づいてリファクタリングとしてのみ再利用可能になります。
個人的には、特定のクラスをコーディングする必要があるシナリオを推測するよりも、常にリファクタリングを行ったほうがクリーンなコードが生成されることがわかりました。
何よりも、保守容易性はコードを再利用可能にします。
再利用性自体が価値のある目標になることはめったにありません。むしろ、適切に構造化され、保守が容易で有用なコードを作成したことの副産物です。
再利用可能なコードを作成しようとすると、将来のプロジェクトで必要になる可能性のある動作の要件を考慮に入れようとすることがよくあります。これがどれだけ上手になっても、これらの将来を保証する要件を間違えていることに気付くでしょう。
一方、現在のプロジェクトの必要最低限の要件から始めると、コードがクリーンでタイトでエレガントになることがわかります。同様の機能を必要とする別のプロジェクトに取り組んでいるときは、元のコードを自然に適応させます。
選択したプログラミング言語 / パラダイムのベスト プラクティス (Java / C# 型のパターンと SOLID など)、リーン / アジャイル プログラミングの文献、および (もちろん) 本「Code Complete」を参照することをお勧めします。これらのアプローチの長所と短所を理解することで、コーディングの練習が際限なく改善されます。その後、すべてのコードが再利用可能になりますが、設計ではなく「偶然」です。
また、こちらも参照してください:保守可能なコードの記述
「再利用」のほとんどの定義では、少なくとも私の経験では、コードの再利用は神話です。傷があるのがわかりますか？:-)
再利用とは、既存のソース ファイルを取得して、新しいコンポーネントまたはサービスがなくなるまで提出することを意味するものではありません。特定のコンポーネントまたはサービスを変更せずに再利用することを意味します。
最初のステップは、再利用可能なコンポーネントを作成するには、少なくとも 3 回の反復が必要であるという考え方に身を置くことだと思います。なぜ3？コンポーネントを初めて再利用しようとすると、処理できないものが必ず見つかります。だから、それを変更する必要があります。これは、少なくとも再利用可能に見えるコンポーネントが最終的に得られるまで、数回発生します。
もう 1 つのアプローチは、コストのかかる前向きな設計を行うことです。しかし、その場合、コストはすべて前払いであり、メリットは (おそらく) 後で明らかになります。上司が、現在のプロジェクト スケジュールが常に優先されると主張する場合、このアプローチは機能しません。
比較的大きなプロジェクトを作成する場合、さまざまなモジュール (パーツ) を作成します。実際に再利用可能なコードとは、同じ機能を必要とする他のプロジェクトが使用できるライブラリを作成できることを意味します。
そのため、再利用できるモジュールを特定する必要があります。
各モジュールのコア コンピタンスを特定します。たとえば、プロジェクトでファイルを圧縮する必要がある場合は、ファイル圧縮を処理するモジュールが必要です。複数のことをさせないでください。ひとことだけ。
圧縮するファイル、出力、および圧縮形式以外は何も必要とせずに、ファイル圧縮を処理するライブラリ (またはクラス) を記述します。これにより、モジュールがプロジェクトの残りの部分から分離され、別の設定で (再) 使用できるようになります。
最初から完璧である必要はありません。ライブラリを実際に再利用すると、設計上の欠陥が見つかる可能性があります (たとえば、新しい圧縮形式を簡単に追加できるほど十分にモジュール化されていないなど)。 2 回目に修正して、モジュールの再利用性を向上させることができます。再利用する (そして欠陥を修正する) ほど、再利用が容易になります。
考慮すべき最も重要なことはデカップリングです。密結合コードを作成すると、再利用可能性が最初の犠牲者になります。
必要なすべての状態またはコンテキストをライブラリの外に残します。ライブラリに状態を指定するメソッドを追加します。
オブジェクト指向を使用すると、コードをスーパークラスにリファクタリングできます。これはおそらく最も簡単で、最も安価で、最も効果的な種類の再利用です。通常のクラス継承では、「他の状況」について多くのことを考える必要はありません。「全能の」コードを作成する必要はありません。
単純な継承を超えて、再利用はあなたが発明した以上のものです。わずかに異なる問題を解決するために独自のパッケージの1つを再利用したい場合、再利用の状況が見つかります。新しい状況に正確に適合しないパッケージを再利用する場合は、2つの選択肢があります。
コピーして修正してください。あなたは今、ほぼ同様のパッケージをしなければなりません-費用のかかる間違いです。
元のパッケージを2つの状況で再利用可能にします。
再利用するためにそれを行うだけです。これ以上何もない。「潜在的な」再利用や未定義の「その他の状況」について考えすぎると、時間の無駄になる可能性があります。
他の人がこれらの戦術について言及していますが、ここでは正式に説明します。これらの 3 つは非常に遠くまで到達します。
前述のように、モジュラーコードは非モジュラーコードよりも再利用可能です。
モジュラーコードを支援する1つの方法は、カプセル化を使用することです。ここでカプセル化理論を参照してください： http ://www.edmundkirwan.com/
エド。
「クラス継承よりもクラス構成」の概念を追加します（これは、ここで他の回答から派生しています）。このように、「構成された」オブジェクトは、依存するオブジェクトの内部構造を気にせず、その動作のみを気にします。これにより、カプセル化が向上し、保守性が向上します（テスト、気になる詳細が少なくなります）。C＃やJavaなどの言語では、多重継承がないため、多くの場合重要です。これは、継承グラフを回避するのに役立ちます。
上記の項目に追加するには、次のように言います。
次回コードに戻ったときに混乱する可能性があると思われるすべての詳細についてコメントしてください。過度に冗長なコメントは少し面倒ですが、まばらなコメントよりもはるかに優れており、前回行っていた WTF を把握する時間を節約できます。