当依赖项的关键功能被破坏并阻碍开发时该怎么办？

昨天，我在一个Rails 5 API项目上工作，该项目正在使用“ 行为可标记”库来使事物具有标记（例如SE上的问题）。Rails 5目前处于alpha支持状态。当前有一个PR，用于修复等待合并到master中的错误；该错误导致我的功能分支在完成过程中停顿了-由于加载已中断，我无法实现该库的任何功能。

作为快速解决方案，我只是克隆了存储库，用PR所具有的相同代码修复了该问题，然后将我的Gemfile（依赖版本控制文件）指向了我自己的Github分支，直到该错误修复最终合并回master。

我很幸运，修复很简单（并且已经有人完成了此修复程序），因此我能够解决这个问题。但是，如果该库对我的应用程序开发至关重要的话，该怎么办？如果停止我的开发的错误修正对于其他人来说不是一个普遍存在的问题，那么该修正没有像这次一样迅速出现吗？

想象一下，在开发其他依赖功能之前需要先完成此功能 -在这种情况下您会做什么？如果对我来说，标记对接下来的开发工作绝对至关重要，那一切都要依靠它-但对于我的配置来说，标记依赖是错误的呢？当依赖项的关键功能阻碍了一个或多个功能部件的开发时，该怎么办？

而且，当然不能在办公椅上进行数小时或数天的剑战了……

这是您使用开源软件的原因之一，对吗？

您可能会说完全相同的论点：“如果我的昂贵，专有，封闭源代码库突然倒塌了，会发生什么？[大型，整体软件公司]会为我解决这个问题吗？” 使用开源软件，至少您有机会自己修复该错误。

如果您的软件严重依赖开放源代码库，则可以采取以下三项措施来减轻风险：

1. 熟悉代码库，甚至自己做出贡献。这是您选择开源的另一个原因，对吗？

2. 如果第一个库发生故障，则有一个备用库。这就是为什么要编写接口的原因。这样您就可以更改实施方式，对吗？

3. 在对尖端的需求与对稳定性的需求之间取得平衡（即，不要使用alpha软件）。你知道你要进入什么了，对不对？

对于开发中存在错误或功能不足而导致您停止工作的高风险的应用程序，解决方案是不使用高风险库。无聊又ing脚，我知道..

您说这是Alpha版。不要对关键项目使用Alpha版本。它甚至不是beta版本，更不用说1.0了，所以这种事情是可以预期的。在项目中此阶段的全部重点是发现问题并强化项目。

如果您发现自己处在这种情况下，则基本上必须做您所做的事情（我们做的完全一样）。修复它并PR项目。

但是该解决方案使用的是功能更稳定的库，这些库具有已知的功能和API，或者至少保持了与稳定版本的向后兼容性。您应该警惕100％依赖于您无法控制且需要成功的事物。

通常建议将第三方库隐藏在您自己编写的适配器或包装器后面。这具有双重优势：

• 您可以将第三方库换成另一个库，而无需更改任何代码
• 您可以根据自己的适配器接口对其余代码进行编程。如果库暂时出现问题，只需插入自己的存根/伪造或库功能的简化版本即可。这样，就不会阻止对下游功能的开发和测试（即使仍在部署整个程序）。