选择项目技术的封面图片

下面是我为项目选择技术栈时考虑的一些非详尽的事项。所有这些事项的权重在不同项目中有所不同。我所寻找的是：

技术栈的灵活性如何？

项目的定制在何处发生？

这项技术如何影响它所属的更广泛的工作流程和管道？

团队情况

团队是一把双刃剑；有时决策是为我们做出的，而其他时候则是意见的雷区。通常我们需要考虑其他每个人（每个相关的人🫥）的优势和观点。

性能

为什么它表现良好？ 瓶颈在哪里？ 它在大规模下的表现如何（不仅仅是对于一个小的初始存储库）？ 这项技术在大规模时如何管理？ 与其他类似技术相比，这项技术如何？

基准测试

有许多不同的基准测试。您必须查看并考虑与您的用例相关的那些。

测试是如何进行的？ 测试是否标准化且适当？ 它们是否更新？

安全性

是否存在任何重大漏洞？ 是否有解决安全问题的特殊功能？

开发者体验

这是对精神耐力的考验，还是我会在草地上精神愉悦地嬉戏？ 有没有我欣赏的功能？

人们对此有不同的看法——只要看看基于命令行界面（CLI）与基于图形用户界面（GUI）的人群就知道了。如果您更喜欢 GUI 工具，只需准备好面对某个地方的某个人不把您当作严肃的开发者。

可替代性

除了对我的雇主方便之外，那我呢（是的，我肯定在这里把一切都关于我自己）？

如果我想离开，我的雇主会很快找到替代者吗？

旁注：没有必要编造一种使用更复杂的技术就不会被解雇的情况。做好工作，成为一个好员工，他们就不会想解雇你。这不像你在 DevRel 工作。

维护

一旦项目由我或其他人“完成”，维护它有多难？

兼容性/集成

该技术与任何现有技术或工具的兼容性如何？ 该技术如何与我们在技术栈中考虑的其他技术集成（特别是对于测试）？ 集成过程有多无缝？

生态系统和支持

就我而言，如果我选择一种新技术，我要么需要可靠的文档，要么需要一个社区，如果文档不好，我可以向其请教，这通常是情况。

围绕该技术的社区有多强大？ 他们的响应能力如何？ 为开发提供了多少插件/工具？ 文档的可读性如何？

构建速度

信不信由你，并非一切都必须尽快构建。一切都有权衡——如果有时间学习技术以使用适合工作的正确工具，那是更好的。

这需要非常快吗？ 如果是，熟悉程度重要吗？ 从产品中快速产生收入（或有截止日期）是否影响我的决策？ 如果添加某些功能时没有任何现有的插件或库来使其更快，这将如何影响实现时间？ 学习曲线有多陡峭？ 我需要购买培训吗？

成本

在构建时会影响哪些成本和资源？

面向未来

使用过时的技术可能会损害项目。

这项技术是否“面向未来”？ 技术更新的频率如何，即它是否很快会过时，特别是在安全更新或作为依赖项冲突方面存在风险？

供应商锁定

并不总是坏事......但通常不太可取。

是否存在供应商锁定的风险？ 如果需要，切换到不同技术有多容易？

合规/法规

谁知道法律是个事儿？

是否有任何合规和监管要求需要考虑？ 该技术是否符合行业标准和法规？

祝您的项目好运！