タグ付けされた質問 「third-party-libraries」

10
サードパーティのライブラリを使用する-常にラッパーを使用しますか？
私が携わっているほとんどのプロジェクトは、いくつかのオープンソースコンポーネントを使用しています。一般的な原則として、コードのすべてのコンポーネントをサードパーティのライブラリにバインドするのを常に避け、代わりにカプセル化ラッパーを経由して変更の痛みを避けるのは良い考えですか？ 例として、ほとんどのPHPプロジェクトはlog4phpをロギングフレームワークとして直接使用します。つまり、\ Logger :: getLogger（）を介してインスタンス化し、-> info（）または-> warn（）メソッドなどを使用します。ただし、何らかの点で優れた仮想ロギングフレームワークが表示される場合があります。現状では、log4phpメソッドシグネチャに密接に関連するすべてのプロジェクトは、新しいシグネチャに適合するために、数十箇所で変更する必要があります。これは明らかにコードベースに大きな影響を与え、変更は潜在的な問題です。 この種のシナリオから将来の新しいコードベースを保証するために、ロギング機能をカプセル化し、最小限の変更で将来のロギングの動作方法を変更するために、ロギング機能をカプセル化し、簡単にできるようにするラッパークラスをしばしば検討します（そして時々実装します） ; コードがラッパーを呼び出すと、ラッパーは呼び出しをロギングフレームワークdu jourに渡します。 他のライブラリにはもっと複雑な例があることを念頭に置いて、私は過剰に設計しているのですか、それともほとんどの場合賢明な予防策ですか？ 編集：その他の考慮事項-依存性注入とテストダブルを使用するには、とにかくほとんどのAPIを抽象化する必要があります（「コードの実行を確認し、その状態を更新しますが、ログコメントの書き込み/実際のデータベースへのアクセスはしません」）。これは決定者ではありませんか？
13
私の上司は、「ここでは発明されていません」という悪いケースを抱えています[非公開]
私の部門は、顧客データをデータベーススキーマに変換して、ソフトウェアを使用できるようにすることを専門としています。 IDataReader現時点では、99％の時間がかかるC＃アプリケーションがあり、SqlDataReaderクリーニングとマッピングを実行してDataRowオブジェクトSqlBulkCopyに挿入し、a を使用してデータベースに挿入しています。 場合によっては（特にソースデータベースにvarbinaryオブジェクトとして画像が含まれている場合）、このプロセスはサーバーからアプリへのSQL転送で完全に停止し、その後すぐに向きを変えてサーバーに戻ることができます。 変換の一部をSSISパッケージとして書き直せば、大幅にスピードアップできると思います。しかし、私が直面し続ける最大の石垣は、上司がNot Invented Hereのように押し返し、「MicrosoftがSSISのサポートを終了したらどうなるでしょうか。この廃止されたコードはすべて手に入れられます。」 「もし彼らがその機能を削除したら...」を見つけたのはこれが初めてではありません。上司からの答え。古い方法で変換を記述したり、SSISを自己学習したり、利点を実証/テストする新しい方法を記述したりする時間がありません（SSISを使用したことがないため、使用方法を学習する必要があります）。 この状況ではどうすればよいですか？新しいテクノロジーの推進を停止しますか？彼が部門を去るまで待ってください（私は彼の後の部門で2番目にシニアの人ですが、彼が辞める/退職するまでに何年もかかる可能性があります）？彼がサードパーティのツールを恐れないようにする新しい方法を見つけましたか？
6
依存関係を取ることへの恐怖に対処する方法
私が所属するチームは、当社のプラットフォームと統合するために会社のパートナーが使用できるコンポーネントを作成します。 そのため、（サードパーティの）依存関係を導入する際には細心の注意を払う必要があることに同意します。現在、サードパーティの依存関係はなく、フレームワークの最も低いAPIレベルを維持する必要があります。 いくつかの例： フレームワークの最も低いAPIレベル（.NET標準）を維持する必要があります。この背後にある理由は、その非常に低いAPIレベルのみをサポートする新しいプラットフォームがいつか登場する可能性があるということです。 JSONを（デ）シリアライズするための独自のコンポーネントを実装しており、JWTでも同じことを実行中です。これは、フレームワークAPIの上位レベルで利用可能です。 標準ライブラリのHTTP実装に依存したくないため、標準ライブラリのHTTPフレームワークのラッパーを実装しました。 同じ理由で、XMLとの間でマッピングするためのコードはすべて「手作業で」記述されます。 私たちはそれをやりすぎだと感じています。これは私たちの速度に大きな影響を与えると思うので、これにどう対処するのか疑問に思っています。
7
誰も経験のない過度に複雑なセットアップを選択するPM [非公開]
最近、私は作るのが難しくないように思えるプロジェクトを始めました。コンセプトは、時々入力を受け入れなければならないかなりシンプルなアプリケーションであり（おそらく1日10倍）、それらに対していくつかの操作を実行し、すべての結果を収集しようとしました最後に。その後、このアプリケーションは、顧客が結果を表示するために使用できるフロントエンドWebポータルを取得しますが、ロケット科学そのものではありません。 このために、私は最初にPythonの組み込み同時実行ライブラリ（ThreadPoolExecutor）をスマートに使用し、フロントエンドに使いやすいライブラリを使用しました（初心者には簡単で、保守とテストが比較的簡単なため、Flaskを選択しました）。 プロジェクトの半分に達した後、PMは、スレッドの代わりにサードパーティのメッセージキュー機能を使用する必要があり、負荷分散を実装する必要があると述べました。最終的に起こったことは、最終的にCelery、Redis、RabbitMQ、Nginx、uWSGIそして、誰も実際に経験したことのない他の大規模なサードパーティサービスの束。 最終的に、これはスパゲッティコードの束、テスト不能なタスク（サードパーティライブラリの複雑さ、コードのパッチ適用が機能しなかったため）、およびこれらのサービスの付加価値が誰にもわからないために頭痛の種につながります。 「はい、これらのサービスを使用する必要があります」と言う前に、誰もこれらの使用方法を知らないか、競合状態に悩まされているコードを導入する以外に彼らが何をするかさえ知らないことに留意してください。 これについてどうすればよいですか？この時点では、最終製品が当初よりも悪くなったとしても、私たちが持っていたものに戻すにはコストがかかりすぎ、PMはこれらのサービスを使用することに行き詰まっています。彼とこれについて議論するのに使用さえありますか？もっと時間が必要ですか？または厳しい答えは、私は自分の仕事にはあまりにも愚かですか？
12
サードパーティのライブラリを最新の状態に保つ方法は？
10個のライブラリに依存するプロジェクトがあり、プロジェクトのトランク内では、これらのライブラリの任意のバージョンを自由に使用できるとしましょう。だから、私は最新バージョンから始めます。その後、これらのライブラリはそれぞれ月に1回（平均）更新されます。トランクを完全に最新の状態に保つには、ライブラリ参照を3日ごとに更新する必要があります。 これは明らかに多すぎる。通常、バージョン1.2.3はバージョン1.2.2のドロップイン代替品ですが、テストなしでは決してわかりません。単体テストでは十分ではありません。DB /ファイルエンジンの場合、古いバージョンで作成されたファイルで適切に動作することを確認する必要があります。GUIと関係がある場合は、すべてを視覚的に検査する必要があります。等々。 これをどのように処理しますか？いくつかの可能なアプローチ： 壊れていない場合は、修正しないでください。ライブラリベンダーが更新を発行する頻度に関係なく、アプリケーションで使用するときにライブラリに問題がなければ、ライブラリの現在のバージョンを使用してください。小さな増分変更は無駄です。 変更を小さく保つために頻繁に更新してください。いずれにせよいつか更新する必要があるため、いくつかのバージョンを飛び越えて潜在的な問題を蓄積させるのではなく、修正が容易なときに早期に問題に気付くように、頻繁に更新することをお勧めします。 間に何か。スイートスポットはありますか？
1
バニラJSはまだライブラリと見なされますか？
私はごく最近、VanillaJS（ドキュメント？）が99％のブラウザーにバンドルされたばかりのライブラリであり、ネイティブJavaScript（私の人生の衝撃）ではないことを発見しました。私自身のライブラリを書いている間、私は通常すべての有用なことを避けます。ほとんどはライブラリです。今、私は3つの質問があります： VanillaJSはまだライブラリと見なされていますか？ VanillaJSなしでDOMで何かをする方法はありますか？ VanillaJSまたはネイティブJSに基づいた主要なライブラリ（ドキュメントは含まれません）
4
サードパーティのライブラリをより大きなオブジェクトモデルでラップするための手作業を減らすにはどうすればよいですか？
2012年 のこの質問の著者と2013 年のこの質問の著者のように、アプリケーションを適切にテストするためにラップする必要があるサードパーティのライブラリがあります。一番上の答えの状態： 常にインターフェイスの背後にサードパーティのタイプとメソッドをラップする必要があります。これは退屈で痛みを伴う場合があります。コードジェネレータを記述したり、ツールを使用してこれを行うことができます。 私の場合、ライブラリはオブジェクトモデル用であり、その結果、この戦略を成功させるためにラップする必要があるクラスとメソッドの数が多くなります。単に「退屈で痛みを伴う」だけでなく、これはテストの難しい障壁になります。 この質問から4年間で、分離フレームワークが大きく進歩したことを認識しています。私の質問は、サードパーティのライブラリを完全にラップする効果を達成するためのより簡単な方法が今あるのでしょうか？このプロセスの痛みを取り除き、手作業の労力を減らすにはどうすればよいですか？ 私の質問はラッピングの手間を減らすことに関するものなので、私の質問は最初にリンクした質問の複製ではありません。これらの他の質問は、ラッピングが理にかなっているかどうかを尋ねるだけであり、どのように労力を小さく保つことができるかではありません。
5
実装の前にインターフェイスAPIを作成する必要がありますか？
私は最近、より「組織化された」プログラミングを掘り下げてきましたが、実装ではなくインターフェイスにプログラミングする必要があることを学んでいます。それを念頭に置いて、可能であれば実装を記述する前に、インターフェイスでプロジェクトを「スケッチ」する方が良いでしょうか？ サードパーティのライブラリ（Lidgrenなど）を使用する場合は、これらをインターフェイスでラップし、IOCコンテナを介して解決する必要がありますか、それともインターフェイスに公開してもかまいませんか？
1
オープンソースソフトウェアを含めるためのライセンス要件
オープンソースプロジェクトでは、必要な機能を実装するために、ライブラリ（LGPL）として、およびソースコード（非LGPL）としていくつかのその他のオープンソースライブラリが含まれています。新しいBSDライセンスがプロジェクトに選択されました。含まれているオープンソースライブラリは、新しいBSD、MIT、Apache、およびLGPLライセンスでライセンスされていますが、GPLライセンスコードではありません。 これらの他のオープンソースライブラリはどのようにクレジットされるべきですか？ すべてのライブラリライセンスをメインプロジェクトライセンスファイルに含める必要がありますか？ [ヘルプ]-> [バージョン情報]ダイアログとドキュメントでプロジェクトWebサイトへのリンクを提供するだけで十分ですか？ クレジットは本当に必要ですか？
3
どうすれば引数の数を低く保ちながら、サードパーティの依存関係を分離したままにできますか？
サードパーティのライブラリを使用しています。彼らは私たちの意図と目的のために、おそらく次のように実装されたPOJOを渡します： public class OurData { private String foo; private String bar; private String baz; private String quux; // A lot more than this // IMPORTANT: NOTE THAT THIS IS A PACKAGE PRIVATE CONSTRUCTOR OurData(/* I don't know what they do */) { // some stuff } public String getFoo() { …
6
初心者のプログラマーとして、サードパーティのライブラリを使用するよりも独自のライブラリを構築することを優先すべきですか？
Pythonプログラマーとして、必要な機能を含む高度なサードパーティライブラリにジャンプする前に、独自のライブラリを構築して理解することをお勧めしますか？ 一部のプロジェクト（DjangoなどのWebフレームワークなど）は、おそらくこのアプローチには大きすぎます。しかし、他のプロジェクト（Webクローラー、グラフライブラリ、HTMLパーサーなど）は実行可能であるようです。 サードパーティのライブラリに早期に依存すると、私の成長が妨げられるのではないかと心配しています。 注：この質問とこの質問は、学習の利点よりも再利用の効率におそらく集中している経験豊富なプログラマーに焦点を当てているようです。私の質問は、初心者に焦点を当てていると思います。
2
タスクにアプローチする方法が2つある場合、どちらを選択する必要がありますか？
特定のユースケースがあり、インターネットを介してそれを行う3つの方法を見つけました。私はこれらの3つを見つめています。 私は何をすべきかわからないままそこに座る傾向があります-それから何もしません...選択する良い方法はありますか？それらすべてを試してみるべきですか？ 特定のコンテキストをより具体的にするために、ボードゲームグリッドを回転したり、グリッドにズームインしたり、このグリッド上のピースを移動したりできる画面の一部が必要な非常に軽量なボードゲームを作成しようとしています。私はこれを行う方法がわかりませんでしたが、Core Animation、Core Graphics、Sprite Kitのようなものをオンラインで見つけ、それらに対する賛否両論を見ました-たとえば、Spriteキットは高レベルですが、フレームレートを60に保ちます画面で実際に何も動いていない場合、バッテリーの無駄です。Core Animationは低レベルのAPIであり、「最高レベルの抽象化を行う」というAppleのガイダンスに反対しています。使用する3つのことを学びたくありません。1。選択してスタックを解除する方法はありますか？ ソフトウェアの分野全体に当てはまると思うので、これを意図的に漠然とした質問として残しています。
3
異なる依存関係に必要な同じ機能を提供する2つのコンポーネント
Zend Framework 1とDoctrine2をORMレイヤーとして使用して、PHPでアプリケーションを構築しています。すべて順調です。さて、私はたまたまZF1とDoctrine2の両方が独自のキャッシング実装に付属していて、それに依存していることに気付きました。私は両方を評価しましたが、それぞれに独自の長所と短所がありますが、どちらも私の単純なニーズに対して他のものより優れているとは言えません。どちらのライブラリも、実装ではなく、それぞれのインターフェイスに対して作成されているようです。 これが問題であると感じる理由は、アプリケーションのブートストラップ中に、2つのキャッシュドライバーを構成する必要があることです。それぞれに独自の構文があります。この方法でミスマッチが簡単に作成され、このため、キャッシュバックエンドへの2つの接続を設定するのは非効率的です。 今後の最善の方法を決定するつもりであり、あなたが提供できるかもしれないあらゆる洞察を歓迎します。 これまでに考えたのは、4つのオプションです。 何もせず、キャッシング機能を提供する2つのクラスが存在することを受け入れます。 ZendのインターフェースをDoctrineのキャッシング実装に固定するFacadeクラスを作成します。 オプション2、その逆-Fendを作成して、DoctrineのインターフェースをZend Frameworkバックエンドにマッピングします。 multiple-interface-inheritanceを使用して、すべてをルール化する1つのインターフェースを作成し、重複がないことを祈ります（つまり、両方に「save」メソッドがある場合、PHPのために同じ順序でパラメーターを受け入れる必要があります。適切な多型の欠如）。 どのオプションが最適ですか、または「上記のどれにも当てはまらない」のバリエーションがありません。
6
オープンソースライブラリのバグが疑われる場合の対処方法
プロジェクトでは、いくつかのオープンソースライブラリを使用しています。それらの一部で問題が見つかることがあります（ライブラリのバグである可能性が高いですが、特にドキュメントが完全に100％完成していない場合は特に、私たちの側での使い方が間違っている可能性があります）。ライブラリは非常に複雑なことが多いため、問題の原因を特定するためにライブラリをデバッグすることは、かなり難しい場合があります。他にどのようなオプションがあり、どのようにそれらを正確に進めるかをまとめるのを手伝ってくれませんか？ 最近、WindowsでTCMalloc（Googleスケーラブルメモリアロケータ）を使用しているときに奇妙な問題が発生したので、この特定のライブラリに適用される回答を歓迎しますが、より一般的な回答も適しています。 1）プロジェクトの管理者/所有者に支援を求めます。これはどのように行うことができますか？ 2）問題を特定して修正するために誰かを雇う。これを行う方法？特定のライブラリで十分な専門知識を持つ人を見つけるにはどうすればよいですか？ ...他のオプションはありますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.