タグ付けされた質問 「code-reuse」

私は、オブジェクトがコードの再利用に関して配信されていないと言ったことをよく耳にします。同意しますか？あなたは彼らがそうではないと信じているなら、なぜですか？

17 object-oriented  code-reuse 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 約10人以上の開発者のチームリーダーとして、コードの再利用を促進したいと考えています。私たちは多くのコードを書きました。過去数年間、それらの多くは反復的です。現在の問題は、これらのコードの多くが他のコードの複製またはわずかなバリエーションにすぎないことです。 コードをコンポーネントに変換して将来のプロジェクトで再利用できるようにする方法についての動き（ディスカッション）を開始しましたが、問題は、新しい開発者やコンポーネントを知らない他の開発者が先に進むことを恐れていることです自分のことを書いてください。 とにかく、既存のコードを複製してそれを調整したり、独自に作成したりするのではなく、コンポーネントを再利用する/ドキュメントを改善する/基礎となるコンポーネントに貢献するように開発者に思い出させる方法はありますか？ 誰もが使用できるように、コンポーネントを簡単に検出可能、簡単に使用できるようにする方法は？ すべての開発者は再利用可能なコンポーネントの利点を知っており、それらを使用したいと考えています。ただ、それらを発見可能にする方法がわからないだけです。また、開発者はコードを書いているとき、再利用可能なコードを書くべきだと知っていますが、そうする動機がありません。

16 code-reuse 

私はCを初めて使用しますが、一般的なデータ構造とCの一般的な記述に関して、コードの重複が必要な悪なのかどうか疑問に思っています。 hash mapたとえば、一般的な実装を記述しようとすることもできますが、最終結果は常に乱雑になります。また、この特定のユースケースだけに特化した実装を記述し、コードを明確に保ち、​​読みやすくデバッグしやすくすることもできます。後者はもちろん、コードの重複につながります。 一般的な実装は標準ですか、それともユースケースごとに異なる実装を作成しますか？

16 c  code-quality  code-reuse 

HaskellとF＃で働いていることの1つは、私よりも賢い大学の誰かが、おそらく私がやっていることの抽象化をすでに見つけているということです。同様に、C＃とオブジェクト指向プログラミングでは、私がやろうとしていることには関係なく、おそらく「it」用のライブラリがあります。 プログラミングの抽象化を再利用することに重点が置かれているため、1）短くて汚いものをコーディングするか、2）他の誰かのより堅牢なライブラリ/ソリューションを見つけるために同じ時間を費やし、それを使用することの間でジレンマを感じることがよくあります。 最近のように、ここのコーダーの1人がCSVファイル用の（デ）シリアライザを作成しましたが、.NET標準がまだ付属していない場合、そのようなものはおそらくオンラインで見つけるのが非常に簡単だと思わずにはいられませんでしたAPI。 私は、.NET Iで働いて数回のみ、いくつかのメソッド呼び出しまたはオブジェクトか何かがあったことを実現するために、一緒に私が知っている内容に基づいてソリューションをパッチしてきた、けれども彼を責めないで 、多くの場合、同じライブラリに、何をやっています欲しかったのですが、それについて知りませんでした。 これは単に経験不足の兆候ですか、それとも新しいものを書くことと古いものを再利用することの間には常にトレードオフの要素がありますか？私が最も嫌いなのは、すでに知っていて忘れていたソリューションに出くわしたときです。最近、ほとんどの言語にプリパッケージされている大量のコードを消化できない人がいるように感じます。

16 libraries  code-reuse 

例として、Javaでアプリを書いているとしましょう。 アプリは、Pythonで記述されたAPIサーバーと通信します。 PythonサーバーはSQLデータベースと通信します。 JavaScriptで記述されたアプリのWebサイトもあります。 4つの異なる言語を使用すると、本質的に同じデータ構造を4回異なるものにするのは簡単です。 たとえば、User型は次のようになります（擬似コード）： type User { integer id; string name; timestamp birthday; } プロジェクトのすべての部分には何らかの表現が必要でしょうUser。JavaパーツとPythonパーツには、2つの異なるclass宣言が必要です。データベースにはUserテーブル宣言が必要です。そして、フロントエンドサイトUserも代表する必要があります。 このタイプを4回繰り返すことは、「繰り返しはしない」という原則に反します。また、Userタイプが変更された場合、プロジェクトのさまざまな部分でこれらの変更を繰り返す必要があるという問題があります。 Googleのprotobufライブラリは、特殊な構文を使用してデータ構造を記述し、ライブラリが複数の異なるプログラミング言語で構造宣言を生成するというこの問題に対する一種のソリューションを提供することを知っています。しかし、これでも型の検証ロジックを繰り返さなければならないという問題には対応していません。 これに関する本やブログの投稿への提案やリンクはありますか？

12 design-patterns  object-oriented-design  code-reuse 

顧客の支払いの処理に使用するクラスがあります。このクラスの1つを除くすべてのメソッドは、すべての顧客で同じです。ただし、顧客のユーザーが負う金額を（たとえば）計算するものを除きます。これは顧客ごとに大きく異なる可能性があり、カスタムファクタはいくつも存在する可能性があるため、計算のロジックをプロパティファイルのようなものにキャプチャする簡単な方法はありません。 customerIDに基づいて切り替えるいコードを書くことができます。 switch(customerID) { case 101: .. do calculations for customer 101 case 102: .. do calculations for customer 102 case 103: .. do calculations for customer 103 etc } ただし、新しい顧客を獲得するたびにクラスを再構築する必要があります。より良い方法は何ですか？ [編集]「複製」の記事はまったく異なります。私はswitchステートメントを回避する方法を求めているのではなく、このケースに最も適したモダンなデザインを求めています-恐竜のコードを書きたい場合はswitchステートメントで解決できます。そこで提供されている例は一般的なものであり、本質的には「スイッチはある場合には非常にうまく機能し、他の場合には機能しない」と言っているため、役に立たない。 [編集]次の理由から、トップランクの回答（標準インターフェイスを実装する顧客ごとに個別の「顧客」クラスを作成する）を採用することにしました。 一貫性：他の開発者によって作成された場合でも、すべてのCustomerクラスが同じ出力を受け取って返すことを保証するインターフェイスを作成できます。 保守性：すべてのコードは同じ言語（Java）で記述されているため、デッドシンプルな機能を維持するために他の誰かが別のコーディング言語を学ぶ必要はありません。 再利用：コードで同様の問題が発生した場合、Customerクラスを再利用して、任意の数のメソッドを保持して「カスタム」ロジックを実装できます。 親しみやすさ：私はすでにこれを行う方法を知っているので、すぐにそれを完了させ、他のより差し迫った問題に進むことができます。 欠点： 新しい顧客ごとに、新しいCustomerクラスのコンパイルが必要です。これにより、変更をコンパイルおよびデプロイする方法が複雑になる場合があります。 新しい顧客はそれぞれ、開発者が追加する必要があります。サポート担当者は、プロパティファイルのようなものにロジックを追加することはできません。これは理想的ではありません...しかし、サポート担当者が必要なビジネスロジックをどのように書き出すことができるのか、特に多くの例外を伴う複雑な場合（そうである可能性が高い場合）もわかりませんでした。 多くの新しい顧客を追加した場合、うまく拡張できません。これは予期されていませんが、もしそうなった場合、コードの他の多くの部分とこの部分を再考する必要があります。 興味のある方は、Java Reflectionを使用して名前でクラスを呼び出すことができます。 Payment payment = getPaymentFromSomewhere(); try { String …

12 design-patterns  clean-code  code-reuse 

私は年金と投資の面倒を見る銀行の大規模な金融取引システムに取り組んできました。15年間の機能変更後、手動回帰テストのコストはリリースごとに20万ドルに上昇しました。（1,000,000 LOC、1日あたり1,000万ドルの取引）。また、このシステムは、多くのデータを移動する社内の19の他のシステムと連動します。このシステムはJavaで実装されました。 ただし、「再利用」を行うほど、回帰テストのコストが高くなります。（理由は、「タッチするコードをテストする」必要があるためです。また、再利用/共有コードは、タッチされたときに多数の場所に影響を与えます。したがって、「DRY-Do Not Repeat Yourself」 -コードをコピーして貼り付ける金銭的なインセンティブを確認します。これは、回帰テストに大きな影響を与えるため、共有できるコードを変更したくないため、回帰テストのコストを削減するためです。 私の質問は、再利用と回帰テストのコストの関係を説明するソフトウェアエンジニアリングの原則があるかどうかです。 私がこの質問をする理由は、システムをテスト対象のより小さな部品に分解することには、おそらくコスト上のメリットがあるからです。 仮定： 「回帰テスト」とは、「受け入れテスト」を意味します。つまり、環境やデータのセットアップなど、ビジネスに代わってシステムに対して新しいテストを作成したり、古いテストを再利用したりする別のグループです。 大きなリグレッションテストコストに対する大胆な反応は、「より自動化されたテスト」です。これは良い原則です。この環境では、いくつかの課題があります。 （a）自動テストは、システムが高い自動テストカバレッジを持たない限り、システムの境界を越えてあまり有用ではありません。（影響範囲の課題）。 （b）システムが既に大きく複雑な場合、プログラマーの時間や高い自動化されたテストカバレッジへの資本投資に勢いをつけることは文化的に困難です。 （c）自動化されたテストの維持コストはプロジェクトに隠されているため、プロジェクトレベルで簡単に破棄されます。 （d）これは銀行で働くことの文化的現実にすぎません。 （e）私はこの問題を別の方法で解決しようとしています（分解）。

12 code-reuse  acceptance-testing  estimation 

私は単一責任原則（SRP）に準拠し、コードの繰り返しを省略しようとします。しかし、少なくとも意味のある名前付きメソッドへの抽出に抵抗する呼び出しのコードブロックにすぎないコードの繰り返しがある場所がしばしばあります。 DoAction1(); DoAction2(); if (value) DoAction3(); DoAction4(); そのようなコードをメソッドに抽出する最良の方法とその命名方法は何ですか？

11 refactoring  readability  single-responsibility  code-reuse 

ScalaのO'Reillyの本で、コードのコピーアンドペーストが作成することを読みました。 ...コードの肥大化、保守性、スキューの問題が発生し、 文脈の中で歪曲という言葉の明確な定義を見ることができません。コピーペーストの問題は認識していますが、「スキュー」という言葉に当てはめることはできません。これはO'Reillyの本で使用されているため、実際のプログラミング用語が流通していると推測しています。 ポインタはありますか？

11 terminology  code-reuse 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私は、防衛ソフトウェア再利用システム（DSRS）と呼ばれる米国国防総省のソフトウェア再利用イニシアチブに関する90年代前半の論文をいくつか 読んでいます。私が見つけた最新の言及は、2000年のソフトウェア再利用リポジトリの調査の論文にありました。 防衛ソフトウェアリポジトリシステム（DSRS） DSRSは、再利用可能なソフトウェア資産（RSA）[14]を保存および取得するための自動リポジトリです。DSRSソフトウェアは、7つのソフトウェア再利用サポートセンター（SRSC）で再利用可能な資産のインベントリを管理するようになりました。DSRSは、品質の高いRSAの中心的な収集ポイントとして機能し、開発者が既存のソフトウェア製品と要件を一致させる機会を提供することにより、ソフトウェアの再利用を促進します。DSRSアカウントは、政府の従業員と政府プロジェクトを現在サポートしている請負業者の職員が利用できます... ... DoDソフトウェアコミュニティは、ソフトウェアエンジニアリングモデルを現在のソフトウェアサイクルからプロセス駆動型、ドメイン固有、アーキテクチャベース、リポジトリ支援のソフトウェア構築方法に変更しようとしています[15]。この変化する環境では、DSRSはDoD全体で複数の相互運用可能な場所を持つ唯一の既存の展開された運用リポジトリであるため、DoD標準再利用リポジトリになる可能性が最も高くなります。7つのDSRSロケーションは、ほぼ1,000人のユーザーをサポートし、ほぼ9,000の再利用可能なアセットをリストしています。DISA DSRSだけで、3,880個の再利用可能な資産がリストされ、400個のユーザーアカウントがあります... DSRSの長期戦略は、仮想リポジトリをサポートすることです。これらの相互接続されたリポジトリは、ドメイン間およびサービス間で再利用可能なコンポーネントを見つけて共有する機能を提供します。効果的で進化しているDSRSは、DoDソフトウェア再利用イニシアチブを成功させるための中心的な要件です。進化するDoDリポジトリの要件により、実際のリポジトリ操作でのテストをサポートし、DoDユーザーをサポートするために、運用中のDSRSサイトがDISAにあり続けることが要求されます。DSRSの分類プロセスは、顧客サポートを提供するための基本的な技術です[16]。このプロセスは、機能的および技術的な移行戦略を実装するために再利用可能な資産を利用可能にする最初のステップです。 ... [14] DSRS -防衛技術の適応のために、信頼性の高いシステム URL：http://ssed1.ims.disa.mil/srp/dsrspage.html [15] STARS -ソフトウェア技術適応のため、信頼性の高いシステム URL：のhttp： //www.stars.ballston.paramax.com/index.html [16] DE PerryおよびSS Popovitch、「Inquire：述語ベースの使用と再利用」 、Proceedings of the 8th Knowledge-Based Software Engineering Conference、pp。 144-151、1993年9月 。... DSRSは死んでいますか？それについての死後報告はありましたか？ソフトウェアの再利用に関する他の最近の米国政府のイニシアチブまたはレポートはありますか？

11 code-reuse  government 

新しいプロジェクトを始めるときは、コードの再利用について常に考えています。 コードをどの程度再利用可能にする必要がありますか？ これをアプリケーションの範囲に制限する必要がありますか、それともプロジェクトの外部で再利用できるようにする必要がありますか？ ときどき、コードの再利用性が単純な設計の邪魔になるように感じることがあります。コードの再利用についてのあなた自身の理解とアプローチを共有してください。

10 refactoring  code-reuse 

私はフリーランスのビジネスに2年以上携わっています。他の人のためにプロジェクトをしている間、私はプロジェクトで実装する一般的なタスクのコンパイルを構築し、それらをコードに入れました。これは、同じことを何十回も書き直さなくても再利用できるいくつかの関数を備えたライブラリのようなものです。Accessデータベースへのアクセス、FTPからの情報のダウンロードなどについて話しています。 これは法的な観点から受け入れられますか？古いコードを再利用し、それを最初から書き直した場合の違いは何ですか（もう一度自分の頭脳を使用するため、まったく同じロジックです）？ もちろん、私はそれに著作権を保有せず、これらのクラスのソースコードをクライアントに提供します。

10 legal  code-reuse 

コードベースの抽象化が多すぎる（または少なくともそれを処理している）と感じている問題に直面しています。コードベースのほとんどのメソッドは、コードベースの最上位の親Aを取り込むように抽象化されていますが、この親の子Bには、これらのメソッドの一部のロジックに影響を与える新しい属性があります。問題は、入力がAに抽象化されているため、これらのメソッドでこれらの属性をチェックできないことです。もちろん、Aにはこの属性がありません。Bを異なる方法で処理する新しいメソッドを作成しようとすると、コードの重複のために呼び出されます。私の技術リーダーによる提案は、ブール型パラメーターを受け取る共有メソッドを作成することですが、これの問題は、これを「隠された制御フロー」と見なす人がいることです。 、また、この共有メソッドは、小さな属性に分割されたとしても、将来の属性を追加する必要がある場合、一度複雑になりすぎたり複雑になったりします。これはまた、カップリングを増やし、結束を減らし、チームの誰かが指摘した単一責任の原則に違反します。 基本的に、このコードベースの抽象化の多くはコードの重複を減らすのに役立ちますが、メソッドの拡張/変更が最高の抽象化を行うようになっている場合は難しくなります。このような状況ではどうすればよいですか？私は非難の中心にいますが、他の誰もが彼らが良いと思うことに同意することはできませんが、それは結局私を傷つけています。

9 object-oriented-design  class-design  abstraction  code-reuse  dry 

パフォーマンスを犠牲にすることなく再利用可能な関数を作成するにはどうすればよいですか？関数を再利用可能にする方法で関数を記述したい（たとえば、データ環境について仮定しない）状況に繰り返し直面していますが、プログラムの全体的な流れを知っているので、最も効率的ではありません。方法。たとえば、株式コードを検証するが再利用可能な関数を記述したい場合、レコードセットが開いているとは限りません。ただし、関数が呼び出されるたびにレコードセットを開いたり閉じたりすると、数千行をループするときにパフォーマンスに大きな影響が出る可能性があります。 だからパフォーマンスのために私は持っているかもしれません： Function IsValidStockRef(strStockRef, rstStockRecords) rstStockRecords.Find ("stockref='" & strStockRef & "'") IsValidStockRef = Not rstStockRecords.EOF End Function しかし、再利用性のためには、次のようなものが必要になります。 Function IsValidStockRef(strStockRef) Dim rstStockRecords As ADODB.Recordset Set rstStockRecords = New ADODB.Recordset rstStockRecords.Open strTable, gconnADO rstStockRecords.Find ("stockref='" & strStockRef & "'") IsValidStockRef = Not rstStockRecords.EOF rstStockRecords.Close Set rstStockRecords = Nothing End Function 数千行/レコードにわたるループ内から呼び出されたときに、そのレコードセットを開いたり閉じたりするパフォーマンスへの影響は深刻ですが、最初の方法を使用すると、関数の再利用性が低下するのではないかと心配です。 …

8 optimization  theory  code-reuse  vba 

ソフトウェアを開発するとき、私は多くの場合、さまざまなプロジェクトで共有および参照できる便利なコードを含む集中型の「コア」ライブラリーを持っています。 例： 文字列を操作する関数のセット 一般的に使用される正規表現 一般的な展開コード しかし、私の同僚の一部はこのアプローチを避けているようです。バグが修正されると、多くのプロジェクトで使用されるコードを再テストすることによるメンテナンスのオーバーヘッドなどの懸念があります。今私はこれをいつすべきかを再考しています。 「コア」ライブラリを使用することが悪い考えとなる問題は何ですか？

8 code-reuse  libraries