选择合适的技术栈：开发者决策指南

介绍

GIF

亲爱的读者朋友，您好！

所以，你现在正处于这样一个阶段：你即将启动一个新项目，现在必须选择采用哪种技术。你是选择更可靠、更传统的技术？还是尝试一下市面上热门的新产品，看看它是否符合预期？

嗯，探索如何处理这些情况是工程过程的一部分，不同的工程师对此会有不同的看法——你可能甚至熟悉许多不同的创作者对使用哪些技术选择的意见。

事实上，你必须找到最适合你（更具体地说是最适合项目）的方法，对我来说，有一个三步流程可以帮助你更自信地做出选择：

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

在本文中，我们将探讨各种情况的例子，最终，您或许能够自己做出选择，并在其中发现属于自己的方法。

评估项目需求

GIF

我在攻读学位期间，遇到一位很棒的教授，他曾经说过：

问题会选择工具，而不是你。

您是在创建一个简单的个人作品集？一个用于识别狗和猪的算法？还是一个需要同时处理大量请求的大型SaaS产品？

所有这些情况都会对你选择的工具产生重大影响。你可以用任何你想要的东西构建一个简单的工具组合，甚至可以出于兴趣去探索各种有趣的工具和随机库。但这可能并不一定适用于庞大的 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 框架。

关键在于：这些项目的存在是为了让你尝试新事物并爱上它们。解决老问题的新方案层出不穷，所以，你要抓住的是它们能为你带来什么——如果你确信某项技术能为你带来巨大的价值（通常体现在性能和用户体验方面），那么你不妨深入学习一下，看看它是否能帮助你解决当前的问题。

评估学习曲线和技术特点

学习曲线也是一个非常重要的衡量指标。你或你的团队成员对某些技术的了解程度如何？他们是熟悉这项技术，还是只是听说过？

短期生产力

你必须考虑到这一点，因为它会直接影响你的工作效率，进而影响你的截止日期。如果你时间非常紧迫，那么现在可能不是测试一个你不确定能否解决问题的全新工具的最佳时机。所以，问问自己：这个工具的学习曲线会对我们的工期造成很大影响吗？我们是否已经掌握了相关的知识？

诸如此类的问题可能会让你因为时间限制而排除一些其他技术——你可能需要在以后的小型项目中学习这些新技术，这也没关系。记住，学习通常是一个缓慢的过程，精通也需要时间，但最终可能会在规模化和维护便捷性方面获得回报。

社区支持

评估学习曲线时，另一个重要的考虑因素是所选技术的资源可用性和社区支持。成熟的技术通常拥有丰富的文档、教程以及庞大的开发者社区，可以随时寻求帮助。而新兴技术虽然可能提供令人兴奋的功能，但资源可能较为有限，这会影响学习过程和故障排除——一开始可能感觉很棒，但当你需要独自编写一个完整的日历时，就会发现并非如此。

着眼长远

最后，还要考虑技术选择的长期影响。我的看法是，你必须密切关注那些尚未发布稳定版本的技术——情况瞬息万变，你最不希望看到的就是仅仅因为所有 API 都发生了变化，就不得不重写整个项目。

考虑到成本

GIF

决策过程中另一个重要的方面是考虑成本。市面上有很多工具，虽然它们看起来很棒，但要轻松部署它们所需的基础设施可能会让你抓狂。

也不要只从金钱价值的角度来考虑问题。如果选择一种技术可能需要花费数小时甚至数天的时间来搭建基础设施，而选择另一种技术只需要执行命令，那么你（或你的工程师）的时间就非常宝贵。你花在产品之外的事情上的每一秒，都是在白白流逝。

对我来说，这是本文赞助商 Encore 的一个非常棒的方面：

对我来说，它最突出的特点之一就是简化的基础设施搭建。想用他们的平台快速部署，并为此付费？没问题。想在每月 5 美元的廉价 VPS 上自托管 Docker 镜像？他们也有相关的文档。

GIF

易于部署以及与客户分离成本/责任是非常重要的功能（例如，Encore 会在您自己的账户或您客户的账户中设置 AWS/GCP 基础设施），但不幸的是，并非所有技术选择都能做到这一点，所以要保持警惕。

在这方面，一个好的经验法则是，在开始编码和选择技术方案之前，先快速概述一下部署部分（如果看起来非常困难，那可能就是一个危险信号）。

⚡ 快来看看 Encore ⚡

所以，如果能考虑一下部署和基础设施成本，他们或许每个月能帮你省下几分钱/几美元 ;)

结论

嘿！你居然走到最后了！

希望您现在觉得选择合适的技术栈不再是一项不可能完成的任务，而变成了一段令人兴奋的旅程！记住，关键在于找到最适合您和您项目的方案。通过评估项目需求、考虑学习曲线并权衡成本，您就能朝着做出明智的决策迈出重要一步（这才是关键所在）。

不要害怕探索新技术，每天都有大量很棒的新东西发布，你可以去看看。但同时也不要低估成熟工具的力量，不要听信那些不发布软件的技术专家的建议。如果它能提供良好的解决方案，符合你或你团队的技能水平，而且价格在你承受范围之内，那么你很可能就走对了路。

所以，卷起袖子，深入研究文档，开始实验吧！谁知道呢？

你或许会在过程中发现你最喜欢的新工具或框架。