选择技术栈是社交决策，而非技术决策

Source: Dev.to

概述

询问一群开发者他们为何选择特定的技术栈，你会听到类似的答案：

• “它的可扩展性更好。”
• “它更快。”
• “它更现代。”
• “它是行业标准。”

但这里有一个大多数人不愿直说的不舒服的真相：

大多数技术栈并不是因为技术上更优而被选择的。
它们是因为人而被选择的。

一旦你看到这一点，就再也无法忽视它。

“最佳技术栈”神话

我们喜欢相信软件决策是理性的。只要比较性能基准、生态成熟度和可扩展性图表，就会有一个技术栈显然是最佳选择。

实际上，大多数现代技术栈都足够好。

• React、Vue、Angular。
• Spring、Node、Django。
• Postgres、MySQL、MongoDB。

在某个阶段，差异不再具有决定性。那么团队为何仍然对技术栈争论激烈？因为决定并不真正关乎代码，而是关乎人、信任、激励和恐惧。

堆栈选择关乎你能雇佣谁

最具影响力且最少讨论的选择堆栈的原因之一：

“我们能为此招聘吗？”

不是：

• “这是最优雅的解决方案吗？”
• “这是最干净的架构吗？”

而是：

• 有没有可用的开发者？
• 新员工能快速上手吗？
• 这会吓跑候选人吗？

一个技术上“更好”但没人熟悉的堆栈往往是商业负担，而非优势。团队并不选择最优的堆栈；他们选择能生存下来的堆栈。

熟悉胜过卓越 每次

这里有一个残酷的事实：团队更倾向于使用他们熟悉的技术栈，而不是更好的技术栈。

为什么？ 因为熟悉可以降低：

• 风险
• 恐惧
• 决策疲劳
• 责任感

如果熟悉的技术栈出现问题，大家都知道该如何调试。如果使用“聪明”的技术栈出错，往往会有人被指责。因此，人们默认使用以前用过的技术——不是因为它是最好的，而是因为它更容易辩护。

技术栈决策是政治性的（是的，政治）

• 房间里声音最大的人
• 资历最高的工程师
• 架构师的过去经验

有时选择技术栈仅仅是因为：

“这就是我上家公司使用的，而且效果很好。”

这不是技术理由。这是社会证明。而且它的影响力极其强大。

“Modern” Often Means “Socially Accepted”

注意，当出现以下情况时，技术栈会突然被称为“现代”：

• 大公司采用它们
• 它们总是被影响者提及
• 招聘信息中提到它们

“Modern”并不意味着更好。它往往意味着可以在不解释的情况下安全选择。选择流行的技术栈可以保护决策者。如果失败了，他们并不是鲁莽——他们只是跟随了潮流。

每个技术栈选择背后的隐藏问题

人们真正想了解的是：

不是：

• “这是不是最快的？”
• “这是不是最干净的？”

而是：

• 会有人把责任推到我头上吗？
• 这会拖慢招聘进度吗？
• 这会导致启动时间更长吗？
• 这会在后期维护时给团队带来更多麻烦吗？

这些是人性的顾虑，而非技术层面的。

这就是堆栈辩论永无止境的原因

你是否注意到堆栈辩论很少达成一致？那是因为你们讨论的并不是代码，而是：

• 身份
• 经验
• 自尊
• 风险容忍度

两位开发者可以审视同一个问题并选择不同的技术栈——这都是基于合理的社会因素。两者都不算“错误”。

为什么这很重要（尤其是对开发者）

了解这些会改变你对以下方面的思考方式：

• 职业发展
• 学习优先级
• 项目决策

它解释了为什么：

• “较差”的技术栈仍能存活
• “更好”的技术栈会消亡
• 旧系统会持续存在
• 简单的工具会占主导

它同样说明了仅学习“最佳”技术并不足够。关键在于：

• 团队能否使用它？
• 人员能否维护它？
• 组织能否支持它？

真正的技能不是选择技术栈

真正的技能是知道何时技术栈的选择重要——何时不重要。优秀的工程师不会对工具过于执着。他们关注：

• 团队
• 沟通
• 持久性
• 变更

他们明白软件的寿命比潮流更长——而人的寿命比代码更久。

最终思考

如果你正处于职业生涯的早期，这会让人感到解放。它意味着你不必追逐每一种“热门”技术。你不需要完美的技术栈。你需要了解权衡、人员以及上下文。

因为在真实的工作中：

最好的技术栈并不是基准测试最高的那一个。
而是团队能够真正构建、维护并共同演进的那一个。

我很好奇——这也是最佳讨论的起点 :)

你是否曾见过一个“技术上更好”的栈输给了一个更熟悉的栈？
你认为这是什么原因导致的？

让我们聊聊吧。 👇