正确的选择大于努力

作为软件专业人员或发烧友，在技术组件方面，我们不知所措。 仅查看消息队列空间，您就可以选择Kafka，RabbitMQ，ActiveMQ，HornetQ等，也可以使用大型云提供商之一的托管服务。 使用所有这些选项，我们如何开始知道哪种最适合我们的用例？

这个话题一直困扰着我一段时间，在我最近参加PyCon的Apache Kafka “羽毛之鸟”会议上，这个话题冒出来。 在我作为专业开发人员的职业生涯中，这也是我能够尝试并完善自己的思想的主题。 我什至在演讲中谈到了如何在不牺牲自己成为下一个Google的梦想的情况下做出正确选择的一部分。

这是评估开源软件组件时要考虑的高级标准。 在讨论了开放源代码之后，我将添加更多一点，特别是关于向他人支付托管或软件即服务解决方案的费用。

开源评估标准

1.项目的年龄和成熟度

您正在考虑的项目的建立程度如何？ 它是否仍处于beta（或alpha？）的状态，已经有十年历史了，可以为它的第三个主要版本（Hadoop！）做准备，还是处于中间位置？

您应该为此标准赋予的权重随该项目在您的体系结构中扮演的角色的关键程度以及涉及的代码量而变化。 例如，如果有人为主要用户存储后端建议了一种全新的数据库技术，我将非常犹豫。 要使JavaScript库在一页的A / B测试变体上呈现图像轮播，可以尝试一些更新的方法。

2.维修保养

几乎与项目的成熟度并驾齐驱，目前的维护几乎是不可谈判的。 为什么采用您知道不会看到可靠更新的内容？

在大多数情况下，您需要一个开源项目，该项目已经超出了最初的公司或发起该项目的个人或个人，并获得了更广泛社区的支持。 足够大的项目最终将演化出自己的基础来支持它们（例如Django Software Foundation），但是如果不是这种情况，请寻求Apache，Linux Foundation或Software Freedom Conservancy等团体的支持。

3.释放速度和稳定性

在进行维护时，请考虑项目的运行速度。 发布的频率如何？ 有规律的节奏吗？ 在内部软件包服务器上维护一个分叉几个月，而等待上游集成错误修复并进行正式发布可能会增加很多开销。

发布时，是否容易分辨出发生了什么变化？ 项目是否使用语义版本控制或类似机制来指示是否存在重大更改？ 是否提供长期支持（LTS）分支机构，这些分支机构从主线开发版本中接收向后移植的安全性和稳定性补丁？

4.安全性

至少要在“ 常见漏洞和披露（CVE）”数据库中搜索您正在考虑的项目。 问的问题：报告了多少个漏洞？ 他们解决了吗，花了多长时间？ 等待补丁时实施变通办法有多困难？ 当这些补丁到达时，应用它们会带来多大的破坏性（例如，将新的资产捆绑包上传到您的CDN或重新启动整个数据库层）？

如果像当今我们许多人一样，您在使用Web服务，请确保熟悉Open Web Application Security Project记录的攻击和缓解措施，并了解如何在环境中采用新代码或系统如何改变威胁模型。

5.标准和项目生态系统

如果存在，该项目是否遵循其概念空间的知名标准？ 如果您和您的团队使用HTTPS和JSON而不是定制的二进制协议，则可以更轻松地集成新的搜索后端。

库是否以您选择的实现语言提供，还是您会手工编写“胶水”代码？ 请记住，如果不存在您所用语言的库，那么对于满足您所有其他要求的项目而言，这绝对是值得的。 这也是参与并回馈社区的好方法！

开发人员是否了解并熟悉此项目？ 如果您需要帮助，是否容易找到熟悉您选择的技术并且能够踏上第一步的人？

6.“开箱即用”

我的朋友和会议组织者乔希·西蒙斯（Josh Simmons）在精彩的演讲中使用了一个很棒的短语，它谈论了为什么新开发者可能会选择Django 。 大致来说，这意味着您使用该软件的前半个小时是什么样的。

在笔记本电脑上安装并运行示例项目有多困难？ 它是否有苛刻的要求，这将使它难以在连续集成环境中运行？ 将其投入生产该怎么办？默认配置可靠可靠吗？或者您将花费数周的时间来调整变量？

7.文件

好的文档绝对是一门艺术，但是任何项目都有基本要求：

• 首先，文档应该存在。
• 它应该是可搜索和可发现的。
• 文档应保持最新状态，并且过时/过时的版本应被明显地标记为此类。

8.支持和承包商

对于任何大型工作的主要组成部分，请调查是否存在咨询和支持生态系统。 如果您是一家小店，无法负担专职数据库管理员（DBA）的费用，那么当您的关系数据库在凌晨2点死亡时，与DBA公司签订合同可能会有所不同，并且您会发现从最后一个月已损坏。

9.许可

最后，您应该知道发布项目的许可证 ，以及它们是否与您自己的许可证兼容。 去年， Facebook为响应社区对其许可证与其他开源项目的兼容性的担忧而向React重新授予了许可证。 为iOS或MacOS开发？ 请记住，GPL许可的软件与Apple App Store的条款不兼容，因此您使用的任何内容都必须获得另一许可。

软件即服务评估标准

上面对开源软件的许多关注也适用于使用托管或托管解决方案。 但是，还有一些项目需要专门考虑这些情况。

10.成本权衡

基于订阅的软件包成本的明显组成部分是金钱。 分析这本身就是一篇文章，但是最重要的元素是找到成本的标准单位（例如，处理的每个请求的成本）以比较​​可能具有不同定价模型的产品。

但是，除了即时标价之外，还有其他费用：

• 您的团队需要花费多少时间在内部构建功能或将现有解决方案组合在一起并学习如何操作它们？
• 在您的团队忙于此的过程中，您从功能开发路线图中会损失什么？您负担不起明天不用吗？

11.自发的大规模（供应商）存在故障

这差不多就是它在锡说，如果你的项目依赖于第三方服务，你有什么影响，如果提供该服务供应商突然 变 出 的 业务 ？

如何使用这些标准

这些标准绝不是考虑软件组件时要考虑的内容的详尽列表。 我鼓励您选择对您和您的项目有意义的项目，并添加针对您情况的其他项目。

对于影响较小工作范围的选择，可以在检查新软件时进行整体考虑并将它们放在脑后，这是很好的选择，但是对于较大的决定，值得在电子表格中跟踪条件并对候选人的实现方式进行数字评分，以在做出决定之前得出总体得分。

狩猎愉快！

对于现代软件堆栈的几乎每个组件，都有无数的开源项目可用-选择的范围可能令人眼花，乱，尤其是当从头开始或一次做出许多选择时。 但是，考虑到上述标准，您应该有能力对自己的需求以及每种选择如何适合或不适合它们进行理性思考。 狩猎愉快！

翻译自: https://opensource.com/article/18/3/pick-right-technology

正确的选择大于努力