依存関係の重要な機能が壊れて開発が妨げられた場合はどうすればよいですか？
昨日、私はRails 5 APIプロジェクトで acts-as-taggable-on ライブラリを使用して、タグにSEの質問のようなものを持たせる）ように取り組んでいました。Rails 5は現在アルファサポート中です。現在、マスターにマージされるのを待っているバグを修正するためのPRがあります。このバグにより、私の機能ブランチが完了の途中で停止しました-ロードが壊れていたため、ライブラリの機能を実装できませんでした。
迅速な修正として、レポジトリのクローンを作成し、PRと同じコードで問題を修正し、バグ修正が最終的にマスターにマージされるまで、Gemfile（依存バージョン管理ファイル）を自分のGithubフォークにポイントしました。
幸運にも、修正は簡単であり（、そして誰かが既にそれを実行していたので）、問題を回避することができました。しかし、このライブラリが私のアプリケーションの開発に不可欠だったとしたらどうでしょう。 myの開発を停止していたバグ修正が他の人々に広まった問題ではなかったとしたら、修正は失敗しました今回のように早く来た？
この機能は、開発前に他の依存する機能で完了する必要があると想像してください。その状況で何をしますか？私にとって、タグ付けが次の開発フレーズに絶対的に重要だった場合、他のすべてはそれに依存していますが、タグ付けの依存関係は私の構成にバグがありますか？ 依存関係の重要な機能が（a）機能の開発を妨害する場合、どうしますか？
そして、確かに、数時間または数日間の オフィスの椅子での剣闘 はオプションではありません...
これがオープンソースソフトウェアを使用している理由の1つですよね？
「非常に高価なプロプライエタリなクローズドソースライブラリが突然倒れたらどうなるか？[大規模なモノリシックソフトウェア会社]で修理してくれる人がいるか？」オープンソースのソフトウェアがあれば、少なくとも自分でそのバグを修正する機会があります。
ソフトウェアがオープンソースライブラリに重大な依存関係を持っている場合、リスクを軽減するためにできることは3つあります。
コードベースに精通し、おそらく自分で貢献することもできます。これが、オープンソースを選択したもう1つの理由です。
最初のライブラリが落ちた場合は、フォールバックライブラリを用意します。これがインターフェイスにプログラミングする理由です。必要に応じて実装を変更できるようにしますか？
最先端のニーズと安定性のニーズのバランスをとってください（アルファソフトウェアを使用しないでください）。あなたは自分が何をしているのか知っていましたよね？
バグや機能の欠如が作業を停止させるリスクが高いアプリケーションを開発するための解決策は、リスクの高いライブラリを使用しないことです。退屈で足りない、知っている。
これはアルファ版リリースだとおっしゃいました。重要なプロジェクトにアルファリリースを使用しないでください。 1.0は言うまでもなく、これはベータ版のリリースではないので、この種のことが予想されます。プロジェクトのこの段階の要点は、問題を見つけてプロジェクトを強化することです。
この状況に陥った場合は、基本的に自分がしたことを実行する必要があります（まったく同じことを行いました）。それを修正し、プロジェクトをPRします。
しかし、解決策は、機能とAPIが理解されたより安定したライブラリを使用するか、少なくとも安定したバージョンへの下位互換性を維持することです。あなたは自分が制御できず、成功するために必要なものに100％依存することに注意する必要があります。
通常、自分で作成したアダプターまたはラッパーの背後にサードパーティのライブラリを隠すことをお勧めします。これには2つの利点があります。
- コードを変更せずに、サードパーティライブラリを別のライブラリと交換できます。
- 残りのコードは、独自のアダプターインターフェイスに対してプログラムできます。ライブラリに一時的な問題が発生した場合は、独自のスタブ/フェイクまたはライブラリ機能の簡易バージョンをプラグインするだけです。このようにして、ダウンストリーム機能のdevelopmentおよびtestingはブロックされません（完全なプログラムの展開はまだですが）。