components - コードの再利用のアイデアをあきらめましたか?

Question

数年前、メディアは、コードの再利用のアイデアが生産性とコードの品質を向上させる簡単な方法であるというあらゆる種類の記事であふれていました。

私が定期的にチェックしているブログやサイトを見ると、「コードの再利用」という考えは時代遅れになっているようです。おそらく、'コードの再利用' の提唱者は全員、代わりに SOA クラウドに参加したのでしょうか? :-)

興味深いことに、Google で「コードの再利用」を検索すると、2 番目の結果のタイトルは次のようになります。

「危険と見なされる内部コードの再利用」!

私にとって、コードを再利用するという考えは単なる常識です。結局のところ、apache commons プロジェクトの成功を見てください!

私が知りたいのは：

あなたまたはあなたの会社は、コードを再利用しようとしていますか?
もしそうなら、どのように、どのレベルで、つまり低レベル API、コンポーネント、または共有ビジネスロジックですか? あなたやあなたの会社はどのようにコードを再利用していますか?
それは機能しますか？

議論？

多くのオープンソースライブラリが利用可能であり、.NET または Java を使用したことがある人は何らかの形でコードを再利用していることを十分に認識しています。それは常識です！

共有ライブラリなどを介したコミュニティ全体ではなく、組織内でのコードの再利用について言及していました。

私は最初に尋ねました。

あなたまたはあなたの会社は、コードを再利用しようとしていますか?
もしそうなら、どのように、どのレベルで、つまり低レベル API、コンポーネント、または共有ビジネスロジックですか? あなたやあなたの会社はどのようにコードを再利用していますか?

私が座っているところから、社内でコードを再利用しようとしている企業の例はほとんどありませんか?

中規模の組織全体で共有される可能性のあるコードをお持ちの場合、この lib/api/etc が存在し、利益をもたらす可能性があることを会社の他のメンバーにどのように通知しますか?

score 10 · Accepted Answer

あなたが参照している記事のタイトルは誤解を招くものですが、実際には非常に読みやすいものです。コードの再利用は非常に有益ですが、すべてにマイナス面があります。基本的に、私の記憶が正しければ、この記事の要点は、コードをブラックボックスに封印し、再訪しないということです。そのため、元の開発者が去ると、知識が失われます。私は要点を理解していますが、必ずしもそれに同意しているわけではありません - 少なくとも「空が落ちている」という点には同意していません。

私たちはコードの再利用を単なる再利用可能なクラスにグループ化するだけではなく、企業全体を見ています。フレームワークの強化や分野横断的な問題への対処のようなものは、すべてのアプリケーションが使用する開発フレームワークに組み込まれます (事前検証と事後検証、ロギングなどを考えてください)。また、複数のアプリケーションに適用できるビジネスロジックも用意されているため、そのようなものは、どこからでもアクセスできる BAL コアに移動されます。

本当に再利用しないのなら、再利用を勧めないことが大事だと思います。これらは十分に文書化されている必要があります。これにより、新しい開発者も同様にスピードを上げるのに役立つリソースを得ることができます。知識が共有されていない場合、コードは最終的に別の場所で再発明され、文書化と知識の共有を厳密に行わないと、重複が発生する可能性があります。

score 5 · Accepted Answer

私たちはコードを再利用します - 実際、私たちの開発者は他のプロジェクトで再利用できるコードを特別に書いています。これは非常にうまくいきました。新しいプロジェクトを迅速に開始することができ、コアライブラリを繰り返し強化しています。

しかし、ただコードを書いて、それが再利用されることを期待することはできません。コードを再利用するには、チームメンバーと他のユーザーの間でコミュニケーションが必要です。これにより、利用可能なコードとその使用方法を人々が知ることができます。

コードの再利用が効果的に機能するには、次のことが必要です。

コードまたはライブラリ自体
複数のプロジェクトまたは取り組みにまたがるコードの需要
コードの特徴/機能の伝達
コードの使い方の説明
時間をかけてコードを維持および改善することへのコミットメント

score 3 · Accepted Answer

コードの再利用は不可欠です。また、可能な限り一般化する必要があり、コードがさまざまな状況により適応できるようになることもわかりました。理想的には、作成するほとんどすべての低レベルライブラリが、異なるアプリケーションの新しい一連の要件に適応できる必要があります。

score 2 · Accepted Answer

コードの再利用は、ほとんどの場合、オープンソースプロジェクトを通じて行われていると思います。再利用または拡張できるものはすべて、ライブラリを介して行われています。Java には、多くのことを行うために利用できるオープンソースライブラリが驚くほど多数あります。それを C++ と比較すると、MFC または Win32 API を使用してゼロからすべてを実装する必要があるのはどのくらい早いかということです。

score 1 · Accepted Answer

「メディアの注目」が足りないのは、みんながやっているからだと思うので、もう書く価値はありません。オブジェクト指向プログラミングと単体テストの意識を高めている人は、以前ほど多くはありません。誰もがすでにこれらの概念を認識しています (使用しているかどうかに関係なく)。

score 1 · Accepted Answer

私の会社での実践に基づく私の個人的な見解：

あなたまたはあなたの会社は、コードを再利用しようとしていますか?

もちろん、すでにニーズに合った別のコードがあれば、それを再利用します。丸穴に四角いペグをあえて使うわけではありません。

もしそうなら、どのように、どのレベルで、つまり低レベル API、コンポーネント、または共有ビジネスロジックですか? あなたやあなたの会社はどのようにコードを再利用していますか?

あらゆるレベルで。私たちのコーディング標準には、実際にはその可能性が非常に低い場合でも、開発者は自分のコードが再利用されると常に想定する必要があると書かれています。下記参照

オブジェクト指向モデルが優れている場合、API はおそらくビジネスドメインを反映しているため、再利用可能なクラスはおそらく追加の労力なしで再利用可能なビジネスロジックと同等です。

実際に再利用する場合の重要なポイントの 1 つは、どのコードが既に利用可能であるかを知ることです。これを解決するには、すべてを中央の場所に文書化します。ドキュメントが最新であり、意味のある方法で検索可能であることを確認するために、少し規律が必要です。

それは機能しますか？

はい。ただし、再利用の可能性または実際の再利用のためではありません。実際には、いくつかのコアライブラリと UI コンポーネントを除いて、大量の再利用はありません。

私の個人的な意見では、真の価値はコードを再利用可能にすることです。そうすることで、願わくばきれいな API は別として、コードは (a) 他の開発者がソースコードを調べずに使用できるように十分に文書化され、(b)置き換え可能になります。これらの点は、継続的なソフトウェアメンテナンスにとって大きなメリットです。

score 1 · Accepted Answer

問題に対するメディアの注目のレベルは、ソフトウェア開発の話であれ政治の話であれ、その重要性とはほとんど関係がありません! 車輪の再発明 (または再保守!) によって開発努力を無駄にしないようにすることは重要ですが、これは今や非常によく知られているため、編集者はこのテーマに関する別の記事に興奮することはないでしょう。

重要性 (または緊急性) の尺度として現在の記事やブログ投稿の数を見るのではなく、古典になった、または専門用語になった概念やバズフレーズ (別の形の再利用!) に注目してください。ソフトウェアおよび開発プロセスで排除できる多くの形式の冗長性についての適切な議論のための DRY の頭字語です。

また、再利用のコストとどこでメリットが得られるかについて、成熟した判断を下す役割もあります。一部のライターは、最初にコードを記述したときに一般化するために労力を費やすよりも、2 回目または 3 回目の使用が実際に行われるまで再利用について心配するのを待つことを提唱しています。

score 1 · Accepted Answer

コードを再利用します。

小規模では、可能な限りコードの重複を避けるようにしています。また、頻繁に使用される多くのコードを含む完全なライブラリがあります。

通常、コードは 1 つのアプリケーション用に開発されます。そして、それが十分に一般的である場合、ライブラリに昇格されます。これはうまくいきます。

score 1 · Accepted Answer

コードを再利用するという考えは、もはや目新しい考えではありません。しかし、それでも非常に良い考えです。.NET フレームワーク全体と Java API は、実際のコード再利用の良い例です。

私たちは、自分たちのプロジェクト用にオブジェクト指向のコードライブラリを開発し、それらを他のプロジェクトで再利用することに慣れてきました。アイデアの自然なライフサイクルの一部です。しばらくの間熱く議論され、その後誰もが受け入れ、それ以上の議論の理由はありません.

score 1 · Accepted Answer

もちろん、コードを再利用します。

すべての言語で利用できるほぼ無限のパッケージ、ライブラリ、共有オブジェクトがあり、開発者のコミュニティ全体がそれらのサポートと更新を支えています。

score 0 · Accepted Answer

コードの再利用は価値があると思いますが、この感情がどこに根付いているかはわかります。私は多くのプロジェクトに取り組んできましたが、再利用可能なコードを作成するために細心の注意が払われ、その後は再利用されませんでした。もちろん、コードを複製するよりも再利用の方がはるかに望ましいですが、企業全体で複数のプロジェクトでオブジェクトを使用することを目的として作成された非常に広範なオブジェクトモデルを数多く見てきました（SOAの同じサービスを異なる方法で使用できる方法のようなものです）。アプリ）が、実際に複数回使用されたオブジェクトを見たことがありません。たぶん、私は再利用の原則をうまく利用している組織の一員ではありませんでした。

score 0 · Accepted Answer

たぶんもっと良い質問は、最近コードを再利用しないのはいつかということです。私たちは、他の誰かが観察した「ベストプラクティス」または事前に発見された「デザインパターン」を使用して構築している状態か、実際にレガシーコード、ライブラリ、またはコピーを構築している状態です。

コードAがコードBを作成するために再利用される程度は、多くの場合、コードAのアイデアがコードBに取り入れられ、デザインパターン/イディオム/本/フリート思考/実際のコード/ライブラリにどれだけ抽象化されるかに基づいているようです。難しいのは、これらすべての優れたアイデアを実際のコードに適用することです。

非技術的なタイプは、再利用のことに熱心になります。彼らは、なぜすべてをコピーして貼り付けることができないのかを理解していません。彼らは、greemelfarmが古いシステムから新しいシステムに以前と同じ情報を伝達するために特別なアダプターを必要とする理由を理解していません。残念ながら、他の何億もの理由のために変更することもできません。

ミュージシャンが1日目から再利用しているのと同じように、技術者は1日目から再利用していると思います。

score 0 · Accepted Answer

私が携わった 2 つのソフトウェアプロジェクトは、どちらも長期にわたる開発でした。1 つは約 10 年前のもので、もう 1 つは 30 年以上使用されており、途中でいくつかのバージョンの Fortran で書き直されています。どちらもコードを大幅に再利用しますが、外部ツールやコードライブラリにはほとんど依存しません。DRY は、C++ で作成された新しいプロジェクトの大きなマントラであり、実際にそれを行うのがより簡単になります。

score 0 · Accepted Answer

コードの再利用は非常に重要な問題です。コードが再利用されない場合、プロジェクトに時間がかかり、新しいチームメンバーが参加するのが難しくなります。
ただし、再利用可能なコードを記述するには時間がかかります。

個人的には、すべてのコードを再利用可能な方法で記述しようとしています。これには時間がかかりますが、その結果、コードのほとんどが組織内の公式インフラストラクチャになり、これらのインフラストラクチャに基づく新しいプロジェクトにかかる時間が大幅に短縮されます。

コードを再利用する際の危険性は、再利用されたコードがインフラストラクチャとして記述されていない場合です。一般的かつカプセル化された方法で、仮定をできるだけ少なくし、ドキュメントと単体テストをできるだけ多く使用すると、コードが予期しないことを行う可能性があります。
また、バグが見つかって修正された場合、または機能が追加された場合、これらの変更がソースコードに返されることはめったになく、その結果、再利用されたコードのバージョンが異なり、誰も知らないか理解できません。

解決策は次のとおり
です。 1. 1 つのプロジェクトだけを念頭に置いてコードを設計および作成するのではなく、将来の要件を考慮して、最小限のコード変更でそれらをカバーできるように設計を柔軟にするように努めます。
2. 使用プロジェクト内で変更せずにそのまま使用するライブラリ内のコードを囲む。
3. ユーザーがソリューションを使用してライブラリのコードを表示および変更できるようにする(使用しているプロジェクトのソリューション内ではない)。
4. 必要に応じてインフラストラクチャに変更を加え、既存のインフラストラクチャに基づいて将来のプロジェクトを設計する。
5. すべてのプロジェクトにインフラストラクチャの維持費を請求し、インフラストラクチャの資金を維持します。

score -1 · Accepted Answer

-1

Maven はコードの再利用を解決しました。私は完全に真剣です。

于 2008-12-25T08:36:47.250 に答える

components - コードの再利用のアイデアをあきらめましたか?

16 に答える 16

Related

Reference