如何挑选合适的技术栈：开发者选型指南

](https://imgapi.imooc.com/6722db3d09e5a53004800259.jpg) 这是一张来自Giphy的表情包图片。

嘿，亲爱的朋友们！

所以你正处于那个阶段，开始一个新的项目时，你现在得选择哪种技术。你是选择更成熟可靠的选项，还是尝试市场上新的热门产品，看看它是否名副其实地好用？

嗯，这确实属于工程过程中的一个环节，用以发现如何处理这些情况，不同的工程师或创作者对此会有不同的见解——你可能已经熟悉了许多关于选择哪种技术的各种意见。

实际上，你需要找到最适合你的方式（特别是对这个项目来说），我认为有三个步骤可以帮助你更坚定地做出选择：

1. 评估项目的需求
2. 评估学习曲线和技术特点
3. 评估成本情况

在这篇文章中，我们将依次举例说明所有情形，到最后你可以自己做选择，并找到你自己的一套方法，在所有这些之中。

在我读大学时，我有一位非常棒的教授曾经说过这样的话：

工具是问题选的，不是你选的。

你是在为自己创建一个个人作品集吗？一个识别狗和猪的算法？还是一个能处理大量并发请求的大型SaaS？

所有这些案例都会对你选择的工具产生重大影响。你可以用任何你想要的东西建立一个简单的作品集（Portfolio），甚至可以看看一堆酷炫的东西和各种随机的库，仅仅出于乐趣，。但这可能并不一定与庞大的 SaaS 生态系统兼容——所以，这就是第一步的坑。

在开始想即将发布的新框架或旧框架的新版本等酷炫的东西之前，试着从需求排除的角度来思考：是否有特定的需求可能排除某个技术选项？如果有，为什么？请尽量不要被某些技术的粉丝制造的假问题所迷惑——你可能听到各种说法：X无法扩展，Y比Z更好，A看起来很丑（说实话，我们每个人都有自己的偏好）。在这里，你的工作是冷静下来，理性地看待问题，理性地思考你的决定。

这里有几个可能适合你的可靠技术选择，在某些情况下可能适合的。

前端开发

我喜欢前端，最让我兴奋的是不断有新东西被引入到前端领域。你可能会觉得这是一大负担和问题，但，我的看法是，每当有人为不同的问题创造新的解决方案时，他们都会把标准提高一个档次——这使得每个人都要不断努力去追赶。下面是一些值得探索的前端技术：

• SvelteKit: 采用编译器驱动的方式构建快速高效的 web 应用
• Qwik: 专注于通过可恢复性实现几乎瞬时的加载
• React （以及其他高级框架如 Next.js）: 以组件化架构和虚拟 DOM 著称
• Angular: 提供包含双向数据绑定的功能齐全的解决方案
• Vue （以及其他高级框架如 Nuxt）: 因其简单易学而著称
• htmx: 允许无需使用重型 JavaScript 框架实现动态内容
• jQuery: 仍然适用于快速 DOM 操作和 AJAX 请求，以及用于查看一些遗留系统

后端开发/全栈开发

在后台，有很多很棒的东西正在被制作，每次迭代都变得更加高效，更加注重开发者的体验。让我们来看看一些值得关注的项目：

• Ruby on Rails: 强调约定优于配置
• Laravel: 面向工匠的 PHP
• Spring Boot (Java): 提供了强大的企业应用程序生态系统
• Node.js: 支持在服务器端运行 JavaScript
• Deno (v2): JavaScript 和 TypeScript 的安全运行环境
• Encore: 一个开源的后端开发平台，简化了从 API 设计到部署的整个后端开发过程。
• Hono: 一个小型、简单且超快的 Deno、Bun 和 Node.js Web 框架

这里重要的是：这些项目是为了让你尝试新事物并爱上它们。新的解决方案层出不穷，所以你真正要关注的是它们能为你带来什么——如果你觉得某种技术能给你带来巨大价值，通常体现在性能和开发体验（DX）上，你可能需要更深入地了解它来解决问题。

畫外音: 學新技術的第11000次。

学习过程也是一个非常重要的衡量点。你们或团队中的其他人对哪些技术了解多少？他们熟悉这些技术，还是仅仅听说过？

短期内的生产力

你必须考虑到这一点，因为它会直接影响你的工作效率，进而影响你的截止时间。如果你有一个非常紧的截止日期，此时测试一个全新的、效果尚不确定的工具可能不是最佳时机，所以问问自己：学习这种工具会不会占用我们很多时间？我们是否已经掌握相关领域的知识？

这样的问题可能会让你根据时间排除一些其他技术——你可能在以后的小项目中需要学习新东西，这也是可以接受的。记住，学习通常起步较慢，掌握它需要时间的积累，但这样可能在规模上和维护的简便性上带来回报。

社区支持

另一个重要考虑点是在评估学习曲线时，该技术是否有可利用的资源和社区支持。成熟的科技通常有大量的文档、教程，以及可以求助的庞大开发者社区。较新的技术虽然可能提供了令人兴奋的新功能，但其可用资源可能较少，这可能会影响学习过程和解决问题的能力——一开始可能很惊艳，但当你需要自己编写一个完整的日历时可能会遇到困难。

考虑长远

最后但同样重要的是，请考虑你所选择的技术的长远影响。我的观点是，你需要意识到还处于不稳定或测试阶段的技术可能存在很大变化——情况可能变得完全不同，你最不希望看到的是仅仅因为所有 API 都发生了变化，你可能需要重写整个项目。

在决策过程中，另一个重要因素是考虑成本。有很多工具虽然看起来很棒，但支持它们运行的基础设施可能会让你抓狂，因为它们的部署并不简单。

尽量不要只从金钱的角度来衡量。如果一种技术可能需要花费数小时或数天来搭建基础设施，而另一种只需要运行几个命令，那么你（或你的工程师）的时间是非常宝贵的，每一分不用于产品开发的时间都是宝贵的时光在流逝。

此处为空
* ** *

对我来说，这是超棒的方面——Encore（本文的赞助商）。

（Encore标志）

对我来说，它的一个突出特点就是简化的基础设施设置。想要快速部署并为此支付一点费用？这个选项也是可以的。想要在你的5美元VPS上托管自己的Docker镜像？相关文档也有说明。

部署的便捷性和成本与关注点的分离是非常重要的特性（例如，Encore会在你自己的或你客户的账户中设置AWS或GCP基础设施），但遗憾的是，并不是每个技术选择都能做到这一点，因此，要留心这一点。

一个不错的建议是，在开始编码和选择技术开始项目之前，快速看一下部署部分（如果看起来极其棘手，那可能是一个警告标志）。

⚡ 查看 Encore 项目 ⚡ 点击这里查看更多内容。

每个月，考虑一下部署和基础设施的成本，这可能帮你省下几便士/美元哦～

嘿！你做到底了！

希望你现在觉得挑选合适的技术栈变得更有趣了，而不是一项不可能完成的任务！记住——这一切都是为了找到最适合你和你的项目的方案。通过评估项目需求、考虑学习曲线并权衡成本因素，你已经朝着做出明智选择迈出了重要一步（这才是重点）。

不要害怕探索新技术，每天都有很多酷炫的新玩意儿等着你去探索，但也别小看了那些成熟的工具，听听那些同样不发布软件的技术大牛怎么说。如果它能提供一个好的解决方案，符合你或你团队的能力，并且不会超出你能承受的费用，那你基本上就走对路了。

所以，卷起袖子，仔细研究文档，开始动手吧！

你可能会在路上找到你喜欢的新工具或框架。