选择正确技术的 11 个注意事项

作为软件专业人士或爱好者，我们在技术组件的选择方面感到应接不暇。仅查看消息队列空间，您就可以从 Kafka、RabbitMQ、ActiveMQ、HornetQ 等中进行选择，或者使用大型云提供商之一的托管服务。面对所有这些选择，我们如何开始知道哪种选择最适合我们的用例？

这是一个困扰我一段时间的话题，它在我最近参加 PyCon 的  Apache Kafka “Birds of a Feather” 会议期间浮出水面。这也是我在职业生涯中作为一名专业开发人员能够尝试并完善我的想法的一个话题。我甚至在关于如何为当前规模做出正确选择而不牺牲您成为下一个 Google 的梦想的演讲中提到了这一点。

以下是评估开源软件组件时要考虑的高级标准。在介绍完开源之后，我将添加更多关于为托管或软件即服务解决方案付费意味着什么的具体要点。

开源评估标准

1. 项目年龄和成熟度

您正在考虑的项目有多成熟？它仍处于测试阶段（或 alpha 阶段？），已有十年历史，并准备发布其第三个主要版本（Hadoop！），还是介于两者之间？

您应该赋予此标准的权重取决于该项目在您的架构中将扮演的角色有多关键以及涉及多少代码。例如，如果有人建议使用全新的数据库技术作为主要用户存储后端，我会非常犹豫。对于用于在页面 A/B 测试变体上渲染图像轮播的 JavaScript 库，较新的东西可能可以尝试。

2. 维护性

与项目的成熟度几乎密切相关的是，当前的维护性几乎是不容谈判的。为什么要采用您知道不会获得可靠更新的东西呢？

在大多数情况下，您需要一个开源项目，该项目已经超越了最初的公司或个人，并获得了更广泛社区的支持。足够大的项目最终会发展出自己的基金会来支持它们——例如 Django 软件基金会——但如果情况并非如此，请寻找 Apache、Linux 基金会或软件自由保护协会等组织的支持。

3. 发布速度和稳定性

在维护性方面，请考虑项目的进展速度。发布频率如何？是否有规律的节奏？在内部软件包服务器上维护一个分支几个月，同时等待上游集成错误修复并进行官方发布可能会增加大量开销。

当发布发生时，是否容易判断发生了什么变化？项目是否使用语义版本控制或类似的机制来指示是否存在重大更改？是否有长期支持 (LTS) 分支可用，这些分支从主线开发版本接收反向移植的安全性和稳定性补丁？

4. 安全性

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

如果像我们很多人一样，您从事 Web 服务工作，请务必熟悉 开放 Web 应用程序安全项目记录的攻击和缓解措施，并了解将新代码或系统引入您的环境会如何改变您的威胁模型。

5. 标准和项目生态系统

如果存在，该项目是否遵守其概念空间的知名标准？如果新的搜索后端使用 HTTPS 和 JSON 而不是定制的二进制协议，您和您的团队将更容易集成它。

您选择的实现语言中是否有可用的库，或者您是否需要手动编写“粘合”代码？请记住，如果您的语言的库不存在，对于满足您所有其他要求的项目来说，这绝对是值得权衡的。这也是参与并回馈社区的好方法！

开发人员是否了解并熟悉该项目？如果您需要帮助，是否容易找到了解您选择的技术并能立即上手的人员？

6. “开箱即用性”

这是我的朋友兼会议组织者 Josh Simmons 在关于为什么新开发人员可能选择 Django 的精彩演讲中使用的一个绝妙短语。它大致意味着您与软件的最初半小时体验如何。

在您的笔记本电脑上安装并运行示例项目有多难？它是否具有挑剔的要求，使其难以在您的持续集成环境中运行？将其投入生产呢——默认配置是否可靠和安全，或者您将花费数周时间来调整变量？

7. 文档

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

• 首先，文档应该存在。
• 它应该是可搜索和可发现的。
• 文档应保持最新，过时/已弃用的版本应明显标记为如此。

8. 支持和承包商

对于任何大型工作的关键组件，请调查是否存在咨询和支持生态系统。如果您是一家负担不起全职数据库管理员 (DBA) 的小商店，那么与 DBA 公司签订合同可能会在您的关系数据库在凌晨 2 点崩溃，并且您发现过去一个月的所有备份都已损坏时，发挥至关重要的作用。

9. 许可

最后，您应该了解项目发布的许可，以及它们是否与您自己的许可兼容。去年，Facebook 重新许可了 React，以回应社区对其许可与其他开源项目兼容性的担忧。为 iOS 或 MacOS 开发？请记住，GPL 许可的软件与 Apple App Store 的条款不兼容，因此您使用的任何东西都需要在其他许可下。

软件即服务评估标准

上述关于开源软件的许多考虑因素也适用于使用托管或托管解决方案。不过，在这些情况下还有一些项目需要考虑。

10. 成本权衡

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

然而，除了直接标价之外，还有其他成本

• 您的团队内部构建功能或拼凑现有解决方案并学习如何操作它们需要花费多少时间？
• 当您的团队忙于处理此事时，您从功能开发路线图中失去了什么，您能负担得起明天没有它吗？

11. 自发的大规模（供应商）存在失败

这基本上就是字面意思——如果您的项目依赖于第三方服务，如果提供该服务的供应商突然倒闭了怎么办？

如何使用这些标准

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

对于影响少量工作范围的选择，可以整体考虑它们，并在检查新软件时将它们记在脑海中，但对于较大的决策，值得在电子表格中跟踪这些标准，并对候选实现进行数值评分，以便在做出决策之前得出总体分数。

祝您狩猎愉快！

现代软件堆栈的几乎每个组件都有无数开源项目可用——选择范围之广令人眼花缭乱，尤其是在从头开始或一次做出许多选择时。但是，考虑到上述标准，您应该能够更好地理性地思考您的需求以及您的每个选项可能或可能不适合它们的方式。祝您狩猎愉快！