依存関係の重要な機能が壊れて開発が妨げられた場合はどうすればよいですか？

昨日、私はRails 5 APIプロジェクトに取り組んでいました。このプロジェクトでは、タグ付きのacts-as-taggable-onライブラリを使用して、タグを付けることができます（SEの質問など）。Rails 5は現在、アルファ版をサポートしています。現在、マスターにマージされるのを待っているバグを修正するためのPRがあります。このバグにより、機能ブランチが完了の途中で停止しました-ロードが壊れたため、ライブラリの機能を実装できませんでした。

簡単な修正として、レポジトリを複製し、PRと同じコードで問題を修正し、バグ修正が最終的にマスターにマージされるまで、Gemfile（依存バージョン管理ファイル）を自分のGithubフォークに向けました。

修正が簡単だった（そして誰かがすでにそれを行っていた）ので幸運に思ったので、問題を回避することができました。しかし、このライブラリがアプリケーションの開発にとって重要だったらどうでしょうか？私の開発を止めていたバグ修正が他の人々に広まっている問題ではなかったので、今回のようにすぐに修正が反映されなかった場合はどうでしょうか？

この機能は、他の依存機能の開発の前に完了する必要があると想像してください-その状況で何をしますか？私にとって、タグ付けが他のすべてが依存している次の開発フレーズにとって絶対に重要だった場合、どうすればタグ付けの依存関係が私の構成にバグを起こすのでしょうか？依存関係の重要な機能が機能の開発を妨げる場合、何をしますか？

そして、確かに、数時間または数日間のオフィスチェアでの剣闘は選択肢ではありません...

これが、オープンソースソフトウェアを使用している理由の1つです。

「非常に高価で、プロプライエタリな、クローズドソースのライブラリが突然倒れた場合、[大規模なモノリシックなソフトウェア会社]でそれを修正できる人がいますか？」について、まったく同じ議論をすることができます。オープンソースソフトウェアを使用すると、少なくともそのバグを自分で修正することができます。

ソフトウェアがオープンソースライブラリに重大な依存関係を持っている場合、リスクを軽減するために次の3つのことができます。

1. コードベースに精通し、おそらく自分で貢献してください。これが、オープンソースを選択したもう1つの理由です。

2. 最初のライブラリが落ちた場合にフォールバックライブラリを用意します。これが、インターフェイスにプログラムする理由です。必要に応じて実装を変更することができますよね？

3. 安定性の必要性に対する最先端の欲求のバランスを取ります（つまり、アルファソフトウェアを使用しないでください）。自分が何に興味を持っているのか知っていましたよね？

バグや機能の欠如が作業を停止させるリスクが高いアプリケーションを開発するためのソリューションは、高リスクライブラリを使用しないことです。退屈で足の不自由な私は知っている..

あなたはこれがアルファリリースだと言いました。重要なプロジェクトにはアルファリリースを使用しないでください。1.0はもちろんのこと、ベ​​ータリリースでもないので、この種のことは予想されています。プロジェクトのこの段階のポイントは、問題を見つけてプロジェクトを強化することです。

このような状況に陥った場合は、基本的に自分がやったことを実行する必要があります（まったく同じことを行いました）。それを修正し、プロジェクトをPRしてください。

しかし、解決策は、機能とAPIを理解したより安定したライブラリを使用するか、少なくとも安定バージョンとの後方互換性を維持することです。あなたは自分がコントロールできず、成功するために必要なものに100％依存することに注意する必要があります。

通常、サードパーティのライブラリを、自分で作成したアダプタまたはラッパーの背後に隠すことをお勧めします。これには2つの利点があります。

• コードを変更せずに、サードパーティのライブラリを別のライブラリと交換できます
• 独自のアダプターインターフェイスに対して残りのコードをプログラムできます。ライブラリに一時的な問題が発生した場合は、独自のスタブ/フェイク、またはライブラリ機能の簡易バージョンを接続してください。この方法では、ダウンストリーム機能の開発とテストはブロックされません（完全なプログラムの展開は依然としてブロックされますが）。