在选择开源库时要考虑哪些因素？ 作者 | Todd Ginsberg 译者 | 无明 编辑 | Vincent AI 前线导读：在这篇文章中，我将讨论在选择开源库时我更看重哪些方面。因为可选择的东西太多了，要挑出既能满足现在的需求，在未来又不会给我们造成麻烦的东西真的是太难了。接下来，让我们一起来看看在选择一个新的开源库时，需要注意的一些事项。 更多优质内容请关注微信公众号“AI 前线”（ID：ai-front） 首先，你真的需要开源库吗？ 保持简单 在查找新的开源库之前，我会仔细考虑是否真的需要添加新的依赖项。我倾向于尽可能少向应用程序添加依赖项，这不是为了节省磁盘空间（现在是 2018 年，硬盘实际上已经很便宜了），而是为了不增加复杂性。为了完成一些简单的事情而添加新的依赖项可能会得不偿失。况且，添加大型依赖项将引入依赖项本身的问题，比如出现 bug 和安全问题的可能性更大了，或者没有直接用到的功能所导致的破坏性变更。所以，如果有可能，我会避免往项目中添加新的依赖项。 你手头的东西是不是已经足够好了？ 如果你使用的是像 Spring 这样的知名框架，那么它可能已经为你提供了你需要的东西。比如，Spring Boot 的主要优点之一是它已经为我们提供了一系列依赖项，我们不用担心它们会不兼容，Spring 团队比大多数团队都更关注安全问题。 没有人遇到过这个问题 在确定你的问题大到需要使用额外的依赖项才能解决之后，如果你找不到可以解决问题的依赖项，那该怎么办？这可能是一个很好的机会，你可以开发一个开源社区之前从未开发过的东西，当然，这也可能说明你走错了方向。并非所有问题都需要使用新的依赖项来解决，所以，请花一些时间思考一下，缺少现成的解决方案是否说明了问题本身就是个问题？ 我更看重哪些方面 以下是我在选择新开源库时会考虑的一些因素。它们的顺序不分先后，我也说不清它们哪个更重要。不同的开源库能够解决不同规模和复杂性的问题，因此，基于这些差异，我认为这些因素当中有一些是必须具备的，但在大多数情况下，它们是相对主观的，并且在某种程度上是可选的。 许可 如果你在大公司工作，他们可能会有一个“可接受”的许可清单可供你选择。在我的公司，如果新依赖项的许可不在这个清单中，我倾向于另寻其他依赖项。通常情况下，获得新许可并不值得。 如果你在小公司工作，或者你的项目只是个人项目，那么就没有这个限制，但你一定要了解你所选择的许可。比如，你有可能被要求公开代码，甚至超出了你能接受的范围。要了解每种许可的含义，我发现这个网站（https://choosealicense.com）很有用。我们最好优先选择具有主流许可的库，而不是那些没有许可或只有私有许可的库。 对于我自己的开源项目，我会选择 MIT 许可（https://choosealicense.com/licenses/mit/），因为我不希望让事情变得太复杂。 简单的说明 如果我看到项目中有一个从未听说过的库，我就会去查它。有时候很难弄清楚一些开源项目究竟是用来做什么的。想想未来加入到你的项目的维护者们，你认为他们会知道这些库是做什么的或者你为什么要选择它们吗？项目应该要有一个简单、专业、明确的说明，用来解释它的目的和使用场景。 测试 还记得我之前说这些因素中的大部分都是主观的吗？但这个不是。如果一个开源库没有测试用例，或者测试用例只覆盖了一小部分有用的代码，我就不会考虑使用它。不一定所有代码都要覆盖到，比如像 getter 和 setter 或其他简单的方法（事实上，这可能是测试用例不成熟的标志！），但重要的代码一定要测试到位，否则 bug 会在各个发布版本之间流转。 无论喜欢与否，如果一个开源库缺乏测试，说明维护人员并不关心这些。你怎么敢把项目的命运与那些没有被认真对待甚至单元测试都不好好做的开源库联系在一起？ 与现有库重叠 你现有的依赖项当中是否有一些已经可以完成新库的大部分工作？是使用同类新库替换当前库，还是为缺失功能寻找不同的库，这个需要慎重考虑。如果你的需求很小，那就自己开发吧（可以从其他开源库中汲取灵感）。我个人不喜欢使用多个依赖项来完成类似的事情。 额外的用途 在为简单的任务选择开源库时，不要因为你觉得将来有可能会用到开源库的其他功能而选择了一个超出实际需要的库。更多的代码意味着更多的错误、更多的漏洞、更多的关联，以及更多无谓的文档。 在开发软件时，复杂性是我们的敌人，所以不要添加功能远超出实际需要的库。 文档和示例 库至少应该要提供一个 README 文件，用于说明它的用法。理想情况下，还应该提供有关所有主要功能的文档和示例，大型开源库就更是如此。如果一个库很小，而且我大概知道如何使用它，那么缺失文档就不会是个大问题。 从本质上讲，项目越大，越是需要文档和示例。 代码质量 因为它们是开源的，所以为什么不看看它们的代码呢？我敢打赌，大多数人都不会深入研究（如果有的话）他们所使用的开源库的代码。在大多数情况下，这完全没问题。 如果有必要的话，你觉得你能找到 bug 并修复它们吗？当你把代码导入 IDE 时，是否出现了很多黄色警告？静态分析工具是否提示你已经生成了太多警告？ 不要将质量差的代码与没有经过精心组织和格式化的代码混为一谈。当然，这些也是需要注意的，但我认为大多数都是主观的（比如，我可能是这个世界上唯一不关心是使用制表符还是使用空格的人）。另外，如果在一开始你不了解项目或系统的架构，代码乍一看可能有点混乱。 安全警告 对于安全问题，你只要搞砸一次，就会有一大堆黑客接踵而至。开源库的维护者应该能够尽量避免或快速修复安全漏洞，这点很重要。如果你的公司拥有 Black Duck（https://www.blackducksoftware.com）或 Snyk（https://snyk.io）许可，我强烈建议先用它们来扫描新的开源库。这两个产品的在线版本都提供了各种开源项目的概述，如果你没有完整版的许可，可以先参考这些信息。 发布频率 对于小型的开源库，因为它们专注于特定的功能，所以我并不会在意它们可能几个月甚至几年都没有更新。如果没有必要，为什么要为了发布而发布呢？反过来说，如果开源库规模比较大，则应该定期更新，利用新的语言特性，修复错误以及提高测试覆盖率。一个大型的开源库如果多年没有更新，你就不应考虑使用它。 问题和错误 大多数开源项目都有问题跟踪系统，否则我就不会考虑使用它。 有时候，如果问题跟踪系统里有很多问题，那说明这个项目的文档化做得不好，或者没有为用户提供更好的提问题的方式。 假设真的有问题存在（我们开发的软件都会有缺陷），它们已经得到修复了吗？维护者是否会对问题做出响应，或者只是把它们关掉？更糟糕的是，问题一直处于打开状态，没有进行任何的诊断或解释？假设你用了这样的库，并出现了严重的问题，你觉得该如何解决？ 开源库的问题会不会得到修复、什么时候修复以及怎样修复，这些都是影响你项目成功的潜在因素，你会冒险把项目的成功与这些问题关联在一起吗？ 社区的态度 我们绝对没有理由使用来自负面人群开发的软件。他们在解决问题时是否表现出有损人格或居高临下的姿态？如果是，那就不要考虑使用这个库。不过，这样的情况非常罕见，大多数社区都是非常好的，而且有些社区的人很乐意为你提供帮助（例如 Kotlin 社区）。 如果你不巧撞见了那种罕见的不良社区，那么赶紧掉头走人，人生苦短，不要在上面浪费时间。 流行度 尽管行业有这种趋势，但我并不会根据 GitHub 上的 Star 数来衡量一个开源项目的实用性。不过，我会试着了解人们对我计划使用的库有哪些看法。一方面，我不会仅仅因为某个库很流行就选择它，另一方面，我也不希望成为某个库的唯一用户。 我发现，一个不是很受欢迎的项目有可能会发展成为被社区广泛接受的项目，但我通常不愿意冒这个风险。最后，我会选择一个依赖项并用它处理一些关键的任务，直到十几年后我的代码无法维护为止。 结 论 我认为最重要的是，较大的项目应该要有更多优质的内容，而较小的项目可能可以减少一些松懈。下面是这篇文章的关键点清单： 如果有可能，尽量不要添加新的依赖项。 请务必先了解开源库的许可条款。 如果不能用简单的话语来描述，那它可能不简单。 如果没有提供测试用例，那就不值得考虑。 它提供的功能不应该与现有的依赖项重叠。 你不需要所有额外的花里胡哨的功能，在选择大型库时要格外小心。 应该提供高质量的文档和示例，特别是大型库。 代码质量很重要，力求易于理解，并且没有太多静态分析警告。 必须提供安全问题跟踪记录和安全问题的快速修复。 大型项目应该要定期发布。 应该要有快速诊断和及时修复错误和问题的历史。 没有人必须为生活中负面的东西埋单。 流行度并不代表一切，但它确实能说明一些问题。 如有疑问，请参阅第一点。 英文原文： https://todd.ginsberg.com/post/the-art-of-picking-dependencies/ 如果你喜欢这篇文章，或希望看到更多类似优质报道，记得给我留言和点赞哦！