在最近的聊天中，我听到了这样一句话：

优秀的高级开发者应该能够使用任何语言进行编程。

作为一个在多个技术栈中摸爬滚打多年的人，这让我开始思考。语言灵活性是高级工程师的核心特质吗？还是深度专业化更加有价值？

在我近18年的职业生涯中，使用了多种语言，细细数来有 C#、Java、JavaScript/TypeScript、C++、Ruby、PHP、Python、Perl 和 ActionScript。

我还尝试过其它不太出名的语言。我不是那种喜欢炫耀的人，也不是一个精通多语言的编程高手。这只是在这个行业待得够久才会遇到的情况。

早在1999年，安德鲁·亨特和大卫·托马斯就在《程序员修炼之道》一书中建议开发人员“每年至少学习一门新语言”。

我认为这有点过头了，因为我们不应该陷入过度逼迫自己的陷阱，但是……这不仅仅是为了充实我们的简历，更是为了拓展我们的思维。不同的语言体现了不同的解决问题的方法，无论你日常使用什么语言，接触这些方法都能丰富我们的工具箱。

如果没有这种经验，我们最终可能会“自食其果”，看不到其他选择。例如，我曾多次目睹这种情况，后端开发人员为了避免接触 JavaScript 而构建复杂的变通方案，却没有意识到这样做只会让他们的生活更加艰难，而不是更轻松。

嘿，我也有过类似的经历，我曾经讨厌 JavaScript，更讨厌 TypeScript，后来被迫用 Perl 写代码，就离开了这个项目。不过，我还是转变了，并踏上了属于自己的旅程。

回想起来，每次学习一门新语言，我都会为我的主力技术栈带来新的见解。我坚信，精通不止一门你最喜欢的语言，就能打开通往新思维的大门。

学习语言 vs. 流利地说语言

当开发人员切换语言时，无论好坏，他们都会带着自己的习惯。

看看资深 Java 或 C# 开发者编写的 TypeScript 代码。你经常会看到一些不必要的类层次结构、依赖注入和存储库模式，而其实更简单的方法效果会更好。他们只学习了语法，却没有学习其中的哲学。

我见过.NET 和 Java 程序员在使用 Node.js 时遇到困难，因为他们试图将其强行塞入一些不合适的模式。Node.js 在架构上比企业级 C# 或 Java 更接近 Go 的极简主义，但他们没有意识到这一点。

人们用不同的语法编写 C#。

这就像口语一样——学习课堂英语和用英语进行会话是不同的。学习语法并不意味着你能编写出符合语言习惯的代码，从而充分利用语言的优势。

过渡需要时间。你可能在一周内就能学会 Go 的语法，但理解它的生态系统和惯用语则需要更长的时间。大多数人会在 3-6 个月后达到生产力平台期，但真正的流利程度则需要更长的时间。

何时添加新语言才有意义

我见过一些案例，在技术栈中添加一门新语言是值得的。原因很少与具体的技术有关，而是与行业现状有关。

在某些情况下，使用新语言是有意义的：

当特定业务问题需要时。有时，特定服务会受益于使用特定语言编写。例如，在使用 Node.js 并需要 CPU 密集型操作（例如 TypeScript 迁移）时，为该特定组件使用性能更佳的语言就是个明智之举。

说到它对招聘和留住人才的帮助，我有几个客户从 C#/Java 迁移到了 Node.js，因为他们发现这样更容易招聘开发人员。他们构建的系统实际上并不需要 C#/Java 带来的繁琐复杂；除了熟悉之外，没有任何商业优势。

当它开启新的职业机会时。我个人曾经受益于更新我的 Java 技能。我的大多数客户都使用 Java，因此这项投资在我的咨询工作中获得了丰厚的回报。有些语言也正在变得过时。它们仍然需要，但市场正在萎缩（Cobol，加油！）。

但说实话，并非所有技术实验都适合投入生产。关键问题是这样的，

“我们可以用 X 写这个吗？”

但

“谁来长期维护这个X代码？”

我曾经处理过一个用 F# 编写的定价算法模块。虽然我其实很喜欢 F#，但在当时的情况下，这个决定并不合理。我接手后的首批决定之一就是用 C# 痛苦地重写它。虽然边际效益并没有抵消团队其他成员的认知负担，但这却是典型的简历驱动设计。公司在重写上花了不少钱，但这仍然比雇佣或教新人用 F# 来维护要便宜得多。

在另一个案例中，一个团队引入了 Python 微服务，因为他们认为这样开发速度会更快。结果却发现速度更慢，导致再次重写。该公司甚至没有意识到，他们支付的费用是用于学习实验和后续清理，而不是实际的功能。

这些失败通常是因为人们没有提出尖锐的问题：

这一变化的实际商业驱动力是什么？

在团队学习新知识期间，花费 3-6 个月的时间降低生产力是否值得？

如果编码冠军离开，谁来维护这个准则？

即使出于良好的意图，混合技术也会带来维护挑战。不同技术的小型集成可能会带来业务关键风险。一旦关键人员离职，原本只需 15 分钟就能解决的问题可能会变成数周的调查。

这就是为什么这样的决定通常需要比内部团队更高层次的咨询和确认。

跨越前后端鸿沟

我认为有一个语言学习领域特别重要：前端和后端的区别。

如果你是一名后端开发人员，学习一些前端技术意味着你将不再局限于只完成一半的功能交付。你可以在需要时帮助前端团队，并更好地理解整个系统。

同样，前端开发人员也能从了解服务器端发生的事情中受益。我注意到后端开发人员经常竭尽全力避免编写 JavaScript，即使这是最简单的解决方案。这种抵触最终使他们的工作变得更加困难，而不是更容易。

你不需要成为双方的专家，但拥有足够的知识，来有效地协作可以改善每个人的生活。

回到我们英语课堂的例子。我们学习英语是为了能够沟通，在项目中学习，而不是仅仅局限于母语项目和资源。我们应该同时学习后端和前端技术栈以及前端，这样才不会限制自己。我们仍然可以专注于其中之一，但你应该能够端到端地交付一个功能，从其他人那里获得一些帮助，而不是等待他们。

“但我是一名架构师——我还需要学习新的语言吗？”

我的回答是：绝对如此，甚至可能更加需要。

架构决策会产生深远的影响。如果你没有亲身实践过自己推荐的技术，又如何真正理解它们的利弊呢？你不能根据博客文章和会议演讲，而是要靠实际经验来做决定。

我认识的一些优秀架构师即使不是全职，也仍然会定期在生产系统上编写代码。他们用不同的语言进行原型设计，构建概念验证，并偶尔深入代码库以了解痛点。他们意识到保持技术敏锐是工作的一部分。

如果没有对多种语言和生态系统的实践知识，你如何评估一项新技术何时合适，何时只会增加不必要的复杂性？你如何区分合理的技术顾虑和简单的变革阻力？

停止学习新技术的架构师，很快就会脱离现代发展的现实，他们的团队也会因此受到影响。

找到你的平衡点

那么，这给我们带来了什么？每个高级开发人员都应该能够使用任何一种语言进行编程吗？我认为这有些夸大其词了。

更像是：高级开发人员应该具有相对快速地适应新语言的思维模型，同时认识到真正的掌握需要时间和沉浸。

挑战不在于语言语法，而在于围绕它的框架、库和惯用语。你可能在一周内学会 Go，但这并不意味着你就能写出符合 Go 语言习惯的代码。你很可能写的是 Java 风格的 Go 代码，这完全偏离了主题。

对于组织来说，计算方法略有不同：

• 对于稳定、长期的项目：保持技术一致性通常比引入新语言更重要

• 对于面临特定技术挑战的团队：有针对性地使用专门的语言可能值得投资

• 对于每个人来说：拥有一个评估何时引入新技术的流程至关重要

一个关键的业务问题经常被忽视：引入一门新语言的真正驱动力是什么？团队学习新知识时，是否值得花费 3-6 个月的时间，导致生产力下降？有时值得，但通常不值得。

问题不应该是

“我们可以用 X 写这个吗？”

但，

“谁来长期维护这个X代码？”

谨慎投资增长

学习新语言对个人和组织来说都是一种投资。虽然语法可能很快上手，但熟悉生态系统则需要更长的时间。即使花费数年时间探索一门新语言，许多开发者仍然觉得自己还没有准备好以高级职位加入该语言的真实项目。

但是，每一位称得上高级的开发人员都对其他方法保持着好奇心。他们或许并非精通五种语言，但他们对其它替代方案足够熟悉，能够知道他们的主要工具何时并非最佳选择。

这并不是为了追逐潮流或充实简历。这是为了拓展你的思维模式，让你能够识别跨语言和生态系统的模式。这是为了理解，你母语中“显而易见的解决方案”在另一个语言中可能并不一致。

也许最重要的是，要时刻保持谦逊，认识到何时将问题强行纳入自己喜欢的解决方案中，而不是为眼前的挑战找到正确的方法。

归根结底，编程语言是工具，而不是身份。

我认识的优秀开发者不会称自己为“Java 程序员”或“JavaScript 程序员”；他们是解决问题的高手，会使用合适的工具来完成工作，无论是他们已经使用了十年的工具，还是上个月才开始学习的工具。

那么，你是什么样的想法？欢迎留言。

作者：Oskar Dudycz

编译：场长

来源：架构周刊

https://www.architecture-weekly.com/p/why-we-should-learn-multiple-programming