当您使用的库不再维护时,您会怎么做?

时间:2009-02-07 15:22:45

标签: project

我总是觉得令人沮丧的一件事是我不再使用我使用的库。即使事先查看更新历史记录和社区,我也遇到过后来检查的情况,发现我使用的版本是最后一个版本。

通常这种情况在几个月过去之后就会被忽视,或者发现了一些错误/限制。我在Python中进行编码时经常遇到这种情况,因为我希望升级到新版本的解释器很容易在以前运行良好的库中引入问题。我的问题是:对这种情况的最佳回应是什么?

  • 您是否成为旧图书馆的维护者?即使你只修复了你关心的错误,这仍然是很多工作。特别是如果库很大,很复杂,并且编写的代码不够完善(通常情况下这种情况)。

  • 您是否切换到其他库(如果有的话)?这也是一项重大任务,有可能引入新的错误,特别是如果唯一的替代方案从不同的角度解决问题。即使您有远见为旧库的功能编写抽象层,情况也是如此。

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

我意识到答案取决于具体情况:库的大小,源是否可用,可维护性,代码使用量,代码依赖程度等等。我是寻找各种案件的答案。你对这个问题有什么经验?

5 个答案:

答案 0 :(得分:10)

好吧,你找到了一个减少外部依赖数量的论据......

我在我审计的几个Java项目中遇到过这个问题;似乎人们倾向于在Web上的某个地方找到一个Jar,因为它可以从中获得最微小的重用。结果是一堆混乱的依赖,最终破坏了代码库。我更喜欢谨慎使用外部组件。

在之前询问你可以做什么可能是最有用的。在开始使用外部组件之前,请先评估外部组件的未来生命周期。对其开发者社区及其用户社区的规模进行一些研究。此外,更喜欢使用具有一个或两个“较小”替代品的组件,您也可以使用它。

如果你有一些想要使用的东西,但它只有一两个人在使用它并且没有超出他们自己的项目,那么你应该自己动手 - 或者与维护人员联手组件。

答案 1 :(得分:2)

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

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

事实上,我会说你唯一想要使用第三方开源库的时候是它背后的社区很大(比如说至少有40多个用户)并且它经历了一些发布

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

如果您在此职位上找不到图书馆,请确保从代码中抽象出第三方图书馆,以便将来更换。

答案 2 :(得分:1)

当我的雇主选择Java EE框架时,我们走了出去,发现了一个更新,更好的。幸运的是Spring可用。

答案 3 :(得分:1)

如果源是可用的,许可证是打开的,并且库可以很好地完成工作,您可以选择分叉库。通过这样做,您还可以向其添加新功能。如果库有很多东西需要修复,代码很乱,最好找一些其他的东西来处理。

答案 4 :(得分:1)

出于这个原因,我们更愿意推出自己的产品。我们最终完全控制它,完全了解它的工作原理,我们可以随心所欲地改变它。当责备游戏出现时我们的屁股就行了,我们宁愿降低风险并自己动手。

我们曾经有过一次使用外部库的情况,它被作者改写并重新调整用途,不再符合我们的预期。我们推翻了这个,写了我们自己的版本,然后安全地继续。

最重要的是安全,并尽量降低风险。