私たちは皆、再利用可能なクラスとコードを書きます。
この素晴らしい新しいクラスを何度も再利用できるように、構成可能性を考慮に入れています。
この余分な時間を今使うことで、後で時間とお金を節約できると上司に伝えます。
しかし実際には、サードパーティのライブラリを作成せず、アプリケーション全体の作業に時間を費やしている私たちにとって、再利用するために作成に余分な時間を費やした 1 つのクラスが実際に別のプロジェクトで再利用されることは何回ありますか? ?
ライブラリには、複数のプロジェクトで使用されるオーダーメイドのクラスがいくつありますか?
私の一般的な経験則は次のとおりです。
素晴らしい質問です。
「再利用のための設計」は間違っていると思います。私が書いたコードは、機能し、きれいで、きれいで、再利用可能であることがわかりました. 再利用のための実際の設計は、コードが実際に再利用される最初のときにのみ行われます!
何かを再利用可能にしようと事前に時間を費やすのは、時間の無駄になりがちです。再利用する必要があるものがわからないからです。
そうは言っても、私の仕事では、ほぼすべてのプロジェクトで再利用されるライブラリのコレクション (大規模で 500MB 以上) があります。ほとんどがドメイン固有のものです。
レッピー さんが書きました:
私の一般的な経験則は次のとおりです。
- 1回繰り返す場合は、コピーします。
- 2回繰り返す場合はリファクタリングする
また、バグがある場合に備えて、コードの両方の部分にコメントが追加されていることを確認して、重複を示すようにしてください。ある部分だけを修正して、他の部分では修正したくない (BTDTGTT)。
ロブ
私は XP の方法論 (またはその他の方法論) の専門家ではありませんが、ここでYAGNIの原則を適用できると思います。
再利用する必要がある場合にのみ、再利用のためにコードを変更してください。
私見ですが、特定のコードは頻繁に再利用される可能性が高く、頻繁に再利用できるように準備するのは理にかなっています。他のコードはそうではなく、おそらく当面の問題を解決する以外に開発する必要はありません。
もちろん、違いを伝えるのはNP困難であることに注意してください。:)
私はあなたが継続的に言語を拡張しているLISPモデルが好きです。最終的には、問題のあるドメインのドメイン固有言語になります。私が実際にLispを書いているわけではありませんが、私が最も頻繁に使用する言語で---現在LuaとC ---私は通常、クローンを作成して変更するのではなく、何かをモジュールに引き出して再利用します。
Cプログラマーにとって、このアプローチの典型的な例は、DaveHansonの著書CInterfacesandImplementationsです。Daveは、3つまたは4つのコンパイラを作成する際に持っていた再利用可能なアイデアをすべて取り入れ、それらすべてを1冊の本にまとめました---そしてソフトウェアは無料です。素晴らしいもの。ここで、Cコードを記述して、それを2回使用したい場合は、ハンソンスタイルのインターフェイスを作成します。私がこの用語で行ったいくつかのこと：2次元配列、ブロッキングを伴う2次元配列、2次元ビットマップ、pbmplusファイルのリーダーとライターなど。このインフラストラクチャが整っていれば、私が何年も望んでいたプログラムを簡単に作成できました。それは、本のページのコピーのスキャンから黒いエッジを取り除くことです。
だから私はあなたがそれを再利用したいときに言った人に同意します、それを引き出します---しかし以前はそうではありませんでした。
最良のアプローチは、再利用についてあまり心配せずに、優れたインターフェイスとクラス間の責任の分離を備えたコードを試して設計することだと思います。しかし、少なくともこのように設計すると、再利用の可能性が残されます。経験則としては、「3 か月後にこのコードに戻ってきたら、理解できますか? また、必要に応じてコードを拡張できますか?」と自問することをお勧めします。
IMO業界で最悪の慣行の1つは、チームが独自の「再利用可能な」フレームワークを作成することを許可された場合です....
構成可能性と再利用可能性には違いがあります-前者は、環境が変化した場合など、さまざまな状況で非常に役立ちます-私が理解している方法で物事を構成可能にすることは、ほとんどの場合、コードとデータを分離する場合です-それは本当に良い習慣です。
再利用可能な設計は、複数のプロジェクトのライブラリとして使用することを計画している何かを作成している場合にのみ、本当に役立ちます。年月が経つにつれ、私は YAGNI の原則をますます意識するようになり、最近では、目の前のタスクのためにクリーンで堅牢なコードを書くことを目指しています。私の経験では、何かが再利用される場合、それがどのように再利用される必要があるかを正確に予測できる可能性はほとんどないため、今必要なコードだけを追加する方がはるかに優れています。そうすれば、将来それを再利用する必要がある場合に、必要なことを正確に実行する新しいものを追加することができ、過去に作成した既存の機能を壊すことなく、現在どのように必要になるかを予測しようとします。
これを数回実行すると、ライブラリが安定して堅牢になり、必要なすべてのことを実際に実行するため、変更する必要がないことに気付くかもしれません。未来について推測するのに多くの時間を無駄にするよりも、その進化的な方法。
多くの場合、「再利用可能な」コードは抽象化されモジュール化されたコードであり、私にとっての主な利点は再利用性ではなく、テスト性の向上です。コードを分離してモジュール化すると、通常、テストが容易になるためです。再利用は便利ですが、多くの場合未使用の副作用です。
また、Juval Lowryは、インターフェイスが再利用性の唯一のコンポーネントであると主張しているため、インターフェイスベースのプログラミングを提唱しています。他のものは機能性（再利用が難しい）を暗示していますが、インターフェースは暗黙的に再利用可能なコントラクトのみを定義します。
技術的なユーティリティのレベルを超えると、現実の世界で実際に再利用されることはほとんどありません。
考えてみれば、理由は明らかです。widget_bodger アプリケーションには、不足している機能をアプリケーションに追加するよりも、必要な機能の 90% が含まれているとします。
あるいは、企業が widget_bodger の非常に優れた「ビープ」機能を賞賛し、それを gernerate_executive_expenses アプリケーションに組み込みたいと考えたとします。再利用すると思うかもしれませんが、コードを掘り下げてみると、GEE アプリケーションは会社で最も古いアプリの 1 つであり、C で記述されており、可用性の高いハードウェアで実行する必要があり、再利用できるのは基本的なアルゴリズムだけであることがわかります。 .
二度と必要ないと確信している場合は、気にしないでください。役に立つかもしれないと思っていても、そうではありません。本当に必要なときにリファクタリングしてください...
ただし、再利用可能にしないことは、透明にしないことの言い訳にはなりません。可能な限り透過的にコードを書くときはいつでも、すでに 99% 再利用可能であることが判明しています...
コードを再利用可能にするものについては、さまざまな意見があります。あなたの時間は、コードを明確にし、適切に構成する (つまり、責任を分離する) ために十分に費やされたと思います。
これによる副次的な利点は、再利用性の向上です。主な利点は、コードの理解、変更、およびデバッグが容易になることです。
それをまとめるために。再利用可能にするためだけに、複雑な構成スキーム、拡張ポイント、およびイベントを実行しないでください。新しいニーズに応じてコードを構成できるように、適切な可動部分を見つけるようにしてください。
いくつかはありますが、より多くのプロジェクトは、必要な機能を独自の方法で実行しているため、多くの場合、古いプロジェクトの機能を共食いして、新しいプロジェクトでそれらを再実装することになります. これはまだ重要だと私は主張します-以前にコードを書いたことの利点をまだ得ており、それでも時間を節約できます.
その上、再利用可能性がどこにあるかが明らかになるのは、機能を試して使用するのは2回目だけであり、何かを投機的に一般化しようとすると、ほとんどの場合間違ってしまい、次回は変更する必要があることがわかりました。
他の投稿者が言ったように、コードをコピーして再利用する場合は、コピーしたコードのデバッグを開始したら、これを行ってよかったと思うでしょう。
現在のアプリケーションの外でクラスを使いやすくする方法でコーディングすることに意味がない限り、私はあなたに同意します。ほとんどの場合、これを行わず、ビジネス環境で行う必要はありません。別のアプリケーションが後でこの機能を必要とする場合、コードの抽出と共通化はその 2 番目のプロジェクトの一部として行うことができ、経営陣はこの観点に同意する可能性があります。
ただし、現在のアプリケーションの制約内でコードを再利用できるようにすることをお勧めします。現在の作業範囲内での重複を避けるために、コードをリファクタリングします。こうすることで、後で簡単に作業できます。コードを再利用するのではなく、変更を行います。変更ははるかに一般的です。
私の 2c は、コード再利用の倫理は、単なるプロジェクトの問題ではなく、会社の問題である必要があるということです。つまり、新しいプロジェクトを開始するときの主な関心事は、「この仕事をできる限り迅速に完了するために、他のどのプロジェクトからコードを盗むことができるか」ということです。
これは、「仕事に最適な、または最もトレンディな言語/ツールは何ですか?」という質問と矛盾します。
このアプローチをとる企業は、言語、フレームワーク、および内部コード ベースがすべて一貫しているため、プロジェクトからプロジェクトへと簡単に切り替えることができるエンジニアのプールになります。
マイナス面は、「新しい」言語またはフレームワークへの切り替えが、ある時点で行う必要があるとしても、政治的にはるかに難しいことです。
再利用のもう 1 つの利点は、oode ベースで何が起こっているかを簡単に追跡できることです。100 万行のコードがある場合、アプリケーションが特定の方法で動作するすべての場所を見つけるのに何時間もかかることがあります。最新の IDE では、「参照を検索」をクリックするだけで、数秒以内に、コンポーネント/メソッドが使用されているすべての場所を見つけることができます。これは、新しい機能を追加したり、バグを修正したり、システムの仕組みを知りたい場合に役立ちます。
SOA が失敗したり、まだ解決されていない理由の 1 つは、サービスを再利用するのが難しいことです。具体的すぎて他の場所で使用できないか、一般的すぎて (通常は非常に複雑です)、さまざまなクライアントのニーズを満たしていません。
これは「コードの再利用」ではなく、「サービスの再利用」ですが、共通の概念がいくつかあります。