我放弃了成为一个全栈开发工程师的理想

本文最初发布于 Artur Martsinkovskyi 个人博客，经原作者授权由 InfoQ 中文站翻译并分享。

导读：一提起“全栈开发工程师”，大家的印象肯定是：这号人啊，堪称大神！会很多技术，前端后端都精通，不掌握七八种语言都不好意思出来打招呼，热点技术名词全都知道，也都会点儿；但是呢，单拿出某一项没有一个能称得上精通的，知识面广则广矣，但没有一个精通的。现在还有些人觉得，全栈开发工程师代表了超高的战斗力，什么都会的“Superman”。但是别忘了老祖宗的教导：术业有专攻。成为全栈开发工程师真的应该是我们的目标吗？让我们来看看 Artur Martsinkovskyi 是怎么说的，希望能给读者带来一些启迪！

我除了是个 Ruby 开发人员外，还是个全栈 Web 开发工程师。但是，我已经厌倦了成为这样的角色，有时候，让我从事业务分析师和手动测试工程师的工作，也会令我倍感厌倦。随着时间的推移，这一行业正在越来越深地陷入了以开发人员为中心的工程流程，不知不觉花掉了很多时间；而开发人员一人则承担了越来越多的责任。

很久之前：史前互联网

很久很久以前，就已经有 DBA（数据库管理员）了。而现在你在小隔间里很难再找到这样的数据库管理人员了。如果你在 Indeed.com （全球领先的招聘网站）搜索“fullstack web developer”（全栈 Web 开发工程师），会得到 7000 多个结果，而如果你搜索“Web developer”（Web 开发工程师）则得到 40000 个结果。用户体验工程师和前端开发工程师的两个不同的独立角色也正在慢慢地融合在一起，前提是他们在工作本质上是相同的。越来越多的机构正在物色既能做前端又能做后端，还能参与业务需求开发、编写单元和集成测试的全能大神，要求他无所不能，什么都能干。

消减成本，剩下的都拿走

乍一看，这似乎是个好主意，如果一个人知晓他的需求，完成了从白纸开始到发布所需的一切功能，并控制了整个过程。这对企业来说更为容易：你需要与一个人进行核实，并且开发过程不会因为“这块应由谁来做”的问题而变得过于复杂，还可以降低成本，从而在质量和开发时间上取得一些折衷。而且，由于他们经历了整个过程，而不是从前任留下的工作开始，因此交流和语境转换也不会给他们带来什么影响，这看上去似乎是一个很好的增强做法……如果你对那些专业人员一无所知，那你就会把这些专业人员的角色都塞到一个人身上。

反击复杂性

后端开发是一个非常复杂的领域，涵盖了对网络层、服务器整体工作的方式、部署、AWS/Google/Azure 服务（它们对现代 Web 应用至关重要）、服务器应用程序语言和框架的细节、使用的协议、身份验证、数据库连接和设置以及许多其他内容的理解。前端则包括掌握扎实的 Web 标准、特定浏览器的怪癖和奇异之处、ES5、ES6、CSS、HTML、框架、预处理器、转译器、构建 工具 、用户体验、用户界面、浏览器视角的网络、浏览器存储的知识，有时甚至还包括与 Flutter、Ionic 和 React Native 有关的移动应用的细节。不要让我讨论业务分析师和测试工程师的角色，因为对我来说这俩是完全不同的领域。

每个角色都有自己的学习曲线和需要掌握的基本技能。你不能奢望一个人只阅读几篇文章或者一本书，编写一个应用程序示例，然后就可以给你带来好结果。但你要知道，结果总是不尽如人意。如果你雇佣了全栈 Web 开发工程师，那么你就不会同时雇佣相当于两个半职专家的人员，而是会同时雇佣一个熟练的工程师和一个不熟练的工程师（在最好的情况下，你也可以得到相当于两个还说得过去的半职开发工程师）。即使在一个领域，也需要投入和动力，以保持相关性和卓越性，而不是投入两个或更多的领域上。因为时间是有限的。除非你放弃了自己的个人生活和时间，否则你不可能会取得文体两开花的成功。

广度还是深度？

千万不要误解我的意思，我的本意是说，我认为拓宽知识面，运用对你所负责的部分的理解来更好地完成你所负责的部分，还是有好处的，但要让开发人员成为这样的一个人：对各种领域样样都懂但无一精通，如此一来，会直接影响代码质量、解决方案的选择以及所开发项目的未来。要知道我们的大脑空间是有限的，但我们可以对一个或几个领域的更深、更好的知识来填充它，或者开始汲取多个领域的信息，结果得到的就是对所有事物都是肤浅的了解。这种知识体系创造了信心泡沫，不幸的是，这种信心并不能证明自己的正确性，结果导致了更槽糕的解决方案，如重新发明轮子、错误的技术选型、用显微镜敲钉子。

并非所有成本消减都是有益的

全栈很有趣，因为它似乎是软件工程领域的独特之处。其他领域大多都有分工，你不能指望牙医能够治愈你的心脏病，也不能指望神经外科医生来治愈你的痔疮。全栈应用于软件工程的原因，似乎是因为这一领域的虚拟性和故障安全特性。你的代码质量并不会直接影响用户可见的结果，因此，你大可以在系统崩溃之前，长期使用补丁解决方案进行修补（通常是你不在时经常会出现这种情况）。此外，这种想法在金钱支出的直观层面上来看似乎颇有吸引力，雇佣具有更广泛技能的人（无论人才质量如何），看起来可能会让人觉得，以同样的成本能够做更多的事情，真是美滋滋。

我们得到的是一些平庸的解决方案，这些解决方案都是由那些在特定领域没有足够专业知识，无法发现更好方法的人创建的，他们所掌握的知识都比较粗浅，略知一二，他们的知识体系都是一堆复制粘贴的答案。我们要让那些故步自封的人必须跟上如此多的主题。我们雇来的专业人员并没有创造出什么令人惊叹的东西，因为他们没有足够的时间来为这个领域创造一些价值。我们以较低的开发成本进行开发，得到的是不合格的产品，这一状况在出现 Bug 和客户流失后就会逐渐消失。由于这些问题，项目以这种开发方式进行开发时将不可避免地会遇到。从短期经济角度来看，雇佣全栈开发工程师可能是值得的，但长期来看，它对整个行业和我们建设的项目来说都是有害的。

原文链接：

https://artur-martsinkovskyi.github.io/2019/i-dont-want-to-be-fullstack/