5

我一直觉得令人沮丧的一件事是当我使用的库不再维护时。即使事先查看更新历史和社区，我也遇到过这样的情况，我稍后再查看时发现我正在使用的版本是最后一个版本。

通常，直到几个月过去，或者发现了一些错误/限制，才会注意到这一点。我在用 Python 编码时经常遇到这种情况，因为我想要升级到新版本的解释器很容易在以前运行良好的库中引入问题。我的问题是：对这种情况最好的反应是什么？

  • 你成为老图书馆的维护者了吗？即使您只是修复您关心的错误，这仍然是很多工作。尤其是如果库很大、很复杂，并且代码记录不充分（这种情况经常发生）。

  • 您是否切换到不同的库（如果有）？这也是一项重要的工作，有可能引入新的错误，特别是如果唯一的替代方案从不同的角度解决问题。即使您有远见为旧库的功能编写抽象层也是如此。

  • 你自己滚吗？它最终的代码可能比旧库少，因为您只编写您关心的部分。因此，将来更容易维护。但是现在您已经浪费了几天/几周/几个月的时间来生产可能功能较少的东西，并且肯定会引入大量新错误。

我意识到答案取决于具体情况：库的大小、源是否可用、它的可维护性、您的代码使用了多少、您的代码对它的依赖程度等等。我正在寻找答案在一系列案例中。你对这个问题有什么经验？

4

5 回答 5

10

好吧，您已经找到了一个减少外部依赖项数量的论据……

我在审计过的几个 Java 项目中遇到过这种情况；似乎人们倾向于将在 Web 上某个地方找到的 Jar 放入其中，以便尽可能少地重用它。结果是一堆依赖关系，最终破坏了代码库。我更喜欢谨慎使用外部组件。

询问您之前可以做什么可能最有用。在开始使用外部组件之前，请务必评估它的未来寿命。研究一下它的开发者社区和用户社区有多大。此外，更喜欢使用具有一个或两个您也可以使用的“较小”替代品的组件。

如果您很想使用某些东西，但只有一两个人在使用它，并且在他们自己的项目之外没有太多使用，那么您可能应该自己动手 - 或者与组件的维护者合作。

于 2009-02-07T15:36:10.607 回答
2

我认为您真正的答案是如何选择第三方库以包含在您的代码中。

如果您碰巧喜欢不断将代码升级到该语言的最新版本，那么默认情况下，您只能使用背后有活跃社区的库

事实上，我想说的是，你想要使用第三方开源库的唯一时间是它背后的社区很大（比如至少有 40 多个用户）并且它已经发布了几个版本。

对于商业图书馆，同样的事情也适用于公司将存在多长时间以及有多少其他客户使用它。

如果您在这个位置找不到库，请确保从代码中抽象出第三方库，以便将来替换不难。

于 2009-02-07T15:46:01.867 回答
1

当我的雇主选择的 Java EE 框架破产时，我们找到了一个更新、更好的框架。幸运的是 Spring 可用。

于 2009-02-07T15:27:20.517 回答
1

如果源可用，许可证是开放的，并且库做得很好，你可以选择分叉库。通过这样做，您还可以为其添加新功能。如果库有很多东西要修复并且代码是一团糟，那么最好找到其他可以使用的东西。

于 2009-02-07T15:34:28.893 回答
1

出于这个原因，我们更喜欢自己动手。我们最终可以完全控制它，完全了解它是如何工作的，并且我们可以以任何我们想要的方式改变它。当我们的屁股在玩指责游戏时，我们更愿意降低风险并自己做。

我们曾经遇到过使用外部库的情况，它被作者重写和重新利用，不再符合我们的预期。我们推翻了这一点，编写了我们自己的版本，然后安全地继续。

底线是安全和风险最小化。

于 2009-02-07T15:47:54.017 回答