我应该关心大量的依赖吗？ [英] Should I be concerned with large number of dependencies?

问题描述

我即将在项目中添加 HtmlUnit 库。我解压zip文件，并意识到它已经不止于 12依赖关系。

I was just about to include the HtmlUnit library in a project. I unpacked the zip-file and realised that it had no less than 12 dependencies.

我一直关注引入依赖关系。我想我必须将所有这些依赖关系与应用程序一起发送（在这种特殊情况下为8.7 MB）。我应该打扰检查这些图书馆的安全更新？最后（最重要的是，我最关心的是什么）：如果我想要包含另一个依赖于与这个库相同的库但是具有不同版本的库呢？也就是说，如果例如HtmlUnit依赖于一个版本的 xalan 和另一个我需要的库，取决于xalan的不同版本？

I've always been concerned when it comes to introducing dependencies. I suppose I have to ship all these dependencies together with the application (8.7 mb in this particular case). Should I bother checking for, say, security updates for these libraries? Finally (and most importantly, actually what I'm most concerned about): What if I want to include another library which depends on the same libraries as this library, but with different versions? That is, what if for instance HtmlUnit depends on one version of xalan and another library I need, depends on a different version of xalan?

任务HtmlUnit解决了我的问题，可以手动解决这个问题，但是可能不会那么优雅。

The task HtmlUnit solves for me could be solved "manually" but that would probably not be as elegant.

我应该担心吗？在这种情况下，最好的做法是什么？

Should I be concerned about this? What are the best practices in situations like these?

编辑：我对一般情况感兴趣，而不是特别涉及HtmlUnit。我只是在这里使用它作为一个例子，这是我目前的关注。

I'm interested in the general situation, not particularly involving HtmlUnit. I just used it here as an example as that was my current concern.

推荐答案

小心处理你的依赖。他们可以带给你很多的速度，但可以是一个痛苦的维持下去的道路。这是我的想法：

Handle your dependencies with care. They can bring you much speed, but can be a pain to maintain down the road. Here are my thoughts:

• 使用一些软件来维护您的依赖关系。 Maven是我将用于Java来做到这一点。没有它，你很快就会松动你的依赖关系。


• 请记住，各种图书馆有不同的许可证。不允许给定的许可证适用于您的设置。我为一家软件公司工作，我们不能在我们运送的任何软件中使用基于GPL的库，因为我们销售的软件是封闭源代码。同样，我们也应该避免LGPL，如果我们可以（这是由于一些复杂的律师推理，不要问我为什么）


• 对于单元测试我会说全部出来。如果您将来要重写测试，那不是世界的尽头。甚至可能那个软件的那部分是非常稳定的，甚至甚至不能维持。松散那些并不是那么大的交易，因为你已经获得了巨大的收获速度。


• 某些图书馆比其他图书馆更难取代。有些像婚姻一样，应该能够延续软件的使用寿命，而其他一些只是易于更换的工具。 （Think Spring与xml库）


• 查看社区如何支持旧版本的库。他们是否支持旧版本？当生活继续下去，你被困在一个版本上会怎么样？有没有活跃的社区，还是有自己的技能？


• 你的软件应该持续多长时间？是一年，五年，十年还是更长时间？如果软件的时间跨度很短，那么您可以使用更多的功能来获取所需的位置，因为它不会像升级库一样重要。

• Use some software to maintain your dependencies. Maven is what I would use for Java to do this. Without it you will very soon loose track of your dependencies.
• Remember that the various libraries have different licenses. It is not granted that a given license works for your setting. I work for a software house and we cannot use GPL based libraries in any of the software we ship, as the software we sell are closed source. Similarly we should avoid LGPL as well if we can (This is due to some intricate lawyer reasoning, don't ask me why)
• For unit testing I'd say go all out. It is not the end of the world if you have to rewrite your tests in the future. It might even be then that that part of the software is either extremely stable or maybe not even maintained no more. Loosing those is not that big of a deal as you already had a huge gain of gaining speed when you got it.
• Some libraries are harder to replace later than others. Some are like a marriage that should last the life of the software, but some other are just tools that are easily replaceable. (Think Spring versus an xml library)
• Check out how the community support older versions of the library. Are they supporting older versions? What happens when life continues and you are stuck at a version? Is there an active community or do you have the skill to maintain it yourself?
• For how long are your software supposed to last? Is it one year, five year, ten year or beyond? If the software has short time span, then you can use more to get where you are going as it is not that important to be able to keep up with upgrading your libraries.

这篇关于我应该关心大量的依赖吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！