误解、狂妄、荒诞，全栈编程完全就是一场骗局？

似乎在一夜之间，“全栈”突然就成为了高人气话题，技术领域中的一切从业者似乎也对此坦然接受，不少程序员在面试时也会称“我是个全栈程序员”来包装自己，即便很多时候，他们并没有完全搞清楚全栈到底是什么。

曾有多年 CTO 经验的技术专家 Ted Gross 对于时下很火“全栈”概念表达了自己截然相反的观点：如果一家企业的目标是获得商业成功，那么将“全栈”强加在程序员身上，将是一种可怕的误解与愚蠢的错误；而有些程序员宣称自己拥有全栈能力，这也是一种狂妄的表现。

Gross 认为，全栈是荒诞不经的期望，甚至完全是个骗局，最终通向的也只有惨烈的失败。“全栈”概念的快速异化与市场需求不无关联，目前的行业倾向，正迫使一切不愿自称“全栈”程序员的技术人难以找到理想的工作，而程序员们又需要这份工作。Gross 呼吁企业和程序员以理智的方式认清并接受现实与局限，随着企业在编程方面的需求越来越迫切，大家必须正视且明确自己对于程序员的期望。

如果大家本身就是“全栈程序员”这种新式新词汇所指代的群体中的一员；或者说虽然头衔不这么说（你可以身为 CTO、研发副总裁或者技术负责人等），但确实在负责多种技术方案的管理工作，那我强烈建议各位拿点时间替自己、也替你所在的单位认真读读本文。另外，在这里我要强调一点，如果大家觉得这篇文章冒犯了你的专业，我首先表示诚挚的歉意。但在你愤而离席、甚至已经准备“问候”我个人之前，真的请你先按捺怒火，结合标题以及你自己对“全栈”的态度读完整篇文章。这里，咱们先来点不那么刺激的，就从与全栈编程愿景相关的定义与认知开始谈起。

我也记不清“全栈”这个术语是从什么时候广泛出现在编程社区当中的。不过在我看来，全栈这东西也会像其他很多曾经流行的术语那样，随着时间推移而很快淡出人们的视野。大家对“DevOps”这字眼肯定非常熟悉，它代表的是对不断开发、筹划以及生产周期的基本形式的概括。最近，“CI/CD”也开始流行起来。第一次看到它时，我感觉自己像个傻子，弄不清这到底是在说些啥。没办法，在查询之后，我意识到它代表的是“持续集成/持续部署”…好吧，这个缩写真的有种很搞笑的感觉。真的，这不就是 DevOps 吗，为什么非得整个单独的术语呢？除此之外，还有敏捷、Scrum 以及 Kanban 之类，在我看来都是形式大于实质的典型案例。总而言之，全栈突然就成了高人气话题，技术领域中的一切从业者似乎也对此坦然接受。

反正一夜之间，我在采访或者交流时，不少程序员开始认真地盯着我，然后说“我是个全栈程序员”。跟第一次听到 CI/CD 时一样，我会反问，“全栈是啥意思？”，之后就是他们对自己全栈能力的描（吹）述（嘘）。不过，我发现很多“全栈”程序员其实弄不清下面这些问题：

1. 你说的“全栈”是什么栈？你的公司正在或者打算使用的技术栈有哪些？

2. 你真的在实践中同时使用 Angular、Vue、HTML 以及 React，而且称得上完全了解吗？

3. 你能够使用 NodeJS、Java/Scala、C++、PHP、Python 以及 Golang 进行后端编程吗？你了解并且精通（请注意，不是简历上的那种“精通”）这些语言吗？

4. 你了解 JSON 吗？知道如何在深度嵌套时加以使用吗？

5. 你了解 AWS、Azure 以及其他组件选项吗？你又是否了解 EC2、NAT 网关乃至 AWS 提供的其他超过 1000 种可选模块？

6. 你是 Redis 及 Memcached 领域的专家，并很清楚如何设置并正确使用 Redis 系统吗？你知道 Redis 最适合应用于哪些场景吗？

7. 你同时了解 iOS 与 Android 原生开发，而且能够通过 React 实现非原生开发吗？

8. 你了解 SQL 与 NoSQL 吗？你知道二者之间的区别，以及如何进行操作吗？你了解 MySQL、Postgre/Postgres SQL、MongoDB、Hadoop、Cassandra 以及 Apache Spark 吗？

9. 更重要的是，你知道如何保护自己的数据——包括静态数据与传输数据——吗？

我可能确实有点刻薄，反正交流的时候我就这样不停地提问，完全不需要等待答案。而且相信大家也完全能够轻松把这些问题扩展到几十上百个。任何敢于全面给出肯定答案的家伙，要么是傻子，要么就是骗子。即使如此，我们到底在聊什么“全栈”？首先，请先给出关于全栈的明确定义。反正我是不知道这帮人说的“全栈”到底有多全。

为了理解什么是真正的技术栈，我们先以技术领域当中常见的两个简单相关缩写词说起。技术人员都听说过“LAMP”栈与相对较新的“MEAN”栈。其中 LAMP 代表的是 Linux、Apache、MySQL 以及 PHP。而 MEAN 代表的则是 MongoDB、Express、Angular 以及 NodeJS。可以看到，MEAN 栈当中包含负责前端开发的 Angular，LAMP 栈中则没有。

毫无疑问，如果从这个角度来讲，目前存在的堆栈可能有数百个之多。所有这一切，都是为了识别并阐述特定项目所需要的技术方案而建立。这些词汇只负责定义技术，而没有特别的意图，也决不应该利用他们来定义某一名程序员在特定工作中的实际资质。到这里，我就要正式抛出本文的核心观点了：如果你的目标是获得成功，那么将“全栈”强加在程序员身上，将是一种可怕的误解与愚蠢的错误。

误解

我觉得我们很难把“全栈”编程这种说法的出现，归结于某一个具体的原因。在这里，我只能提出一些理论与假设，尽可能把它们混合起来，然后做出更合理的猜测。我认为最有可能的原因，就是全栈这一理念始于良好的愿望。以程序员为载体将一种专业同另一种专业结合起来，确实是种合乎逻辑的思路，而且也有不少优秀的程序员确实有能力胜任多种技术处理方式。然而，正如其他很多事物一样，“全栈”概念也快速异化，如今成了一个笼统的术语，指在广泛的技术层面当中拥有大量专业知识。这是一种误解，但却稀里糊涂成了最近不少人看待编程工作时的一种预期与要求。下面，我将提出几点背景驱动因素：

1. 资金有限 。 实际上，预算是有的。毕竟无论是在初创企业中还是大型公司内，预算都会有一个具体的数额。只有明确了预算，我们才能确保烧钱的速度不会让整个组织失控，而且公司能够在全周期之内逐步消化可承受的成本。这是一项基本的经济学原理，所有不尊重这项原理的家伙都已经在现实中受到了残酷的惩罚。因此，既然一个编程团队当中，每个人都只是一到两个方面的专家，为什么我们不干脆只请一位能够搞定一切的大拿呢？听起来有道理吧，所以“全栈”就这么诞生了。毕竟，很多企业都要求其 CTO 亲自动手参与工作——或者说是两份工作，一份是管理技术人员，另一份是实际编程。在这样的背景，将各种“专业知识”整合到同一个岗位当中也将顺理成章。这确实能够节约资金，并且通过团队的小型化与紧密化带来其它一些优势。

2. 给编程团队当替补 。 我要强调的另一个重点在于，如果某位程序员生病或者离职，在真正的“全栈”环境中，其他程序员应该能够轻松接替，直到公司找到合适的新员工。毕竟，既然每个人都拥有“全栈”能力，那他们就都应该掌握其他人掌握的知识。换言之，每个人都是全方位的专家，那也就不需要针对某一方位聘用专家了。

3. 对需要多少知识一无所知 。 最近，我跟一位新晋研发副总裁进行了一场开诚布公的交流（面试），他让我谈谈对于“全栈”程序员团队的想法。我回以一个问题，“栈是什么？”他说，大概就是 MongoDB、React、NodeJS 堆栈，其中包括对微服务、Lambda 以及其他 AWS 技术的使用。我想了一秒，意识到直话直说很可能会毁了我的这次面试机会。但对我来说，残酷的真话总比甜蜜的谎言要好。所以我问这位副总裁，他自己是否真的知道自己对程序员提出了怎样的要求。

展开来谈，他提出的要求可以分为以下几个部分：

a. 他们必须了解并精通 NodeJS。 虽然目前人气极高，但 NodeJS 并不只是 JavaScript 的一种扩展，而是一种具有众多可能性与中间件的新语言，要求程序员对同步与异步编程拥有深入的理解。而正确实现微服务这一要求的存在，又把门槛提升到了新的高度——程序员必须真正理解 NodeJS 的工作原理及其在编程结构中的作用，同时非常明确应该做什么、不应该做什么。

b. MongoDB 并不只是一套 NoSQL 数据存储系统。 很多人可能没有意识到，单是 MongoDB 自身就包含超过 200 种可行的语言调用。它还要求程序员深刻理解数据结构，因为其并不属于传统的关系数据库。（即使是在 SQL 系统当中，也需要一名严肃的数据管理者专门负责数据结构问题。）另外，MongoDB 以及任何其他 NoSQL 系统也对非结构化数据的相关知识提出严格要求。这本身就是一门科学。复制和分片呢？索引使用呢？何时使用 map reduce 以及其他技术概念？这些都是非常现实的问题。

c. 接下来是 AWS。AWS 当中包含大量技术成果，Lambda 正是其中之一。 Lambda 目前已经相当流行，但如果未能正确实施，它很快就会成为企业面临的一场噩梦（特别是在成本层面）。更重要的是，AWS 由无数此类即服务选项组成，目前简单的 AWS 堆栈就包括实例、NAT 网关、S3 的使用以及其他 AWS 服务。单是这一点就是一项艰巨的任务，而且极易陷入失控。

d. 我还在回答中加入了其他一些重要，但对方并没有提到的元素。 何时何处使用 Redis？如何使用？如何专业地操作 Redis 本身及其数据？

e. 由谁来负责数据安全？ 数据安全本身又是另一项重要的全职工作，而且在开发周期中经常遭到忽视，这非常可怕。

f.如果这还不足以说明问题，或者说不足以证明一个要求程序员掌握上述一切技能的招聘者本身已经精神错乱，那我们再来聊聊前端。 这样的招聘要求，其实就是认定会有人熟练掌握了所有这些技能，同时还能够使用标准的 UI 与 UX 方案构建起像样的前端。即使不使用难度相对较高的 React，换成 Angular 或者 Vue，我仍然觉得这事没戏——完全没戏。我不在乎大家去吹什么全能大神，我就是不信。

说到这里，相信大家应该已经很清楚，任何“堆栈”都可以分解成几个相关度最高的明确部分。一旦认真完成了堆栈拆分，我们就会意识到其中需要什么知识、不需要什么知识。期望一到两名“全栈”程序员能够吃透这一切，或者至少对其拥有全面的了解，根本就不切实际。

g. 完全就是狂妄的表现 。 没错，我承认某些堆栈（例如 WordPress 以及 Wix 等）可以由一个人搞定。但是，就个人经历来看，任何宣称自己拥有全栈能力的程序员或者 CTO，至少都强调过自己精通多种编程语言、前端以及数据库结构（SQL 与 NoSQL 混合使用）。这完全就是狂妄的表现。

现实

现实情况非常简单。俗话说“独木难支”，好吧，这应该是个成语。反正有些事情一个人就是干不了，这跟业务能力无关。当然，跨界人才是客观存在的，也确实有极少数的从业者能够同时做好几个方面的工作，但这些人开出的薪酬要求，绝对高于企业愿意支付的水平。

同样是现实情况，在讨论“全栈”之前，大家首先得定义堆栈里到底包含哪些内容。如果我们继续聊之前的这个示例，如果 NodeJS 程序员需要同时负责 MongoDB 设置工作，他们了解安全需求吗？我在现实生活中乃至网上看到过无数完全没有安全性可言的 MongoDB 设置结果。另外，这些程序员知道该如何在数据传输过程中采取必要的安全措施吗？他们会理解 bCrypt 与 crypto 之间的区别吗？这样的问题还可以无限延展，而且我们姑且假设有人能够做到。那前端呢？他们还得开发出一套完整的前端（移动与 Web），且同时符合以上要求——这可能吗？

现实情况是，成功的团队当中，每个人都应各司其职。纵观所有堆栈，大家可以按照主要功能将其划分成三大类：

1. 前端

2. 后端

3. 数据库

现实情况是，专业知识之间彼此交叉。我们需要定义某些参数（特别是与 JSON 相关的参数），需要发送哪些参数，以及在必要时应在哪一侧执行计算。

现实情况是，随着企业在编程方面的需求越来越迫切，大家必须进一步明确自己对于程序员的期望。简单上传一份招聘启事，在其中列出一长串语言、技术与要求，然后将职位描述成“全栈程序员”根本就无济于事——也有点作用，证明企业本身根本就不知道自己在说什么。这是种危险的迹象，大家应该将其视为警报，意识到公司并不清楚自己需要哪些专业知识以及如何借此实现商业成功。

现实情况是，你和你的企业需要准确定义所需要的技能内容，需要向其他程序员提供哪些支持，以及如何在可行的预算范围之内开展工作。不管怎么做，我可以向大家保证，请一位能够身兼编程工作的 CTO 再加两名“全栈”程序员，不可能帮你实现这个目标。

现实情况是——请以理智的方式认清并接受现实与局限。

荒诞

你会聘请一位了解 Python 的程序员担任数据科学家吗？我真心希望大家给出的答案是“否”。为什么？很简单，我们都知道数据科学家拥有自己的一套特殊技能组合，而 Python 或者 Java/Scala 只是其中的一小部分。那么，为什么你会考虑一位只能说对 NodeJS 稍有了解的程序员来构建整个前端、后端以及数据库系统？这显然不是错误，而是荒诞了。

但是……但是……我们还要测试呢！没错，肯定会测试。面试人员通过了 Python 测试、NodeJS 测试、数据库测试甚至是一些简单的前端系统测试。这一个表单、那一道试题、再加个响应站点——当然，最后的结果就是你找到了一名出色的“全栈”程序员。他们如此出色，即使你在测试中改用 Golang 或者 Java，他们也能顺利通过。

那么 iOS 原生程序员呢？如果他们既能开发 iOS 应用，又能开发 Android 应用，那不是更好？当然更好喽！他们肯定能够弄清两套系统中的所有细微差别，包括往来于后端当中的数据，这还能有多难，对吧？

顺着这个思路，负责管理后端的程序员肯定也能够搞定整个数据与安全系统。毕竟这也是他们工作中的一部分嘛。

简单的算术结果告诉我们，只需要两名程序员就能完全五份工作。这样，预算空间就显得更充裕啦，公司也绝对会因此而快速发展、腾飞。“全栈”的诱惑其实就是这么来的。但是，在实践当中，各位会慢慢体会到，这只是一种荒诞不经的期望，通向的也只有惨烈的失败。如今，凭借着令人难以置信的 IDE 与其他开发工具，程序员应该能完成一切抛来的任务了吧？错！动动脑子，这现实吗？

打个比方，这就好像指望出任 CTO 的技术管理者同时身兼 COO 与 CFO 职务一样。任何脑袋还正常的人都不会想出这样的主意。那为什么一到了开发层面，程序员就得面对这样的要求？一言以蔽之，永远不要指望“全栈”程序员能够了解一切并精通一切。

失败的序幕

致屏幕前的所有“全栈”程序员：

在对本文表示愤怒、反感或者漠视之前，请先阅读以下部分。我把我的观点表达明确，接下来我会虚心接受大家的反馈。

问题不在大家身上。目前的行业倾向，正迫使一切不愿自称“全栈”程序员的技术人难以找到理想的工作。市场对“全栈程序员”的需求正在迅猛增长，而我们又需要这份工作……还能怎么办？大家别无选择，只能宣称自己拥有“全栈”技能并在背地里恶补那些自己还不熟悉的知识。

然而，这种期望本身必然带来失败的结局。我们只能在某些方面成为专家，而不可能在所有领域都有所建树。被迫钻研自己较为薄弱的技术方向，会给我们带来巨大且不必要的负担，同时挤占自己在真正擅长的领域投入的学习时间。技术系统每 3 个月更迭一次，对于任何从业者来说，我们都几乎不可能跟上所有语言的发展变化。再结合“全栈”这个玩笑一样的背景，死定了，不可能有别的结果。

但是，有些朋友还是要坚持：“我就是全栈程序员。这些我全都懂，我全都能搞定。醒醒吧，全栈是一种历史趋势，不承认也没有用。”

老哥，我劝你醒醒才对。这里我就是要把难听的话说出来——全栈编程完全是个骗局。最后，你只会什么都懂一点，什么都不精通。这时候，如果你的数据库无法返回正确结果，你的后端无法执行正确的计算，或者你的前端没有显示正确的数据，或者你的系统遭到黑客入侵甚至破坏，猜猜锅会甩到谁的身上？毕竟你可是全栈程序员啊，全栈背锅是跑不掉的！

至于业务价值，有些企业为什么能获得成功？就是因为他们很清楚，堆栈中的每个部分都需要专业知识与掌握这些知识的专业人士。而某些企业之所以陷入困境甚至是惹火上身，正是因为他们指望自己的程序员精通一切并能够处理整个堆栈中的所有组成部分。

前端程序员就不应该在数据库结构和信息层面硬掺一脚。后端程序员也不要胡乱插手前端开发的事。在当今时代，也只有真正了解完整背景信息的专家，才能有效解决安全问题。

诚然，某些技术确实可能或者可以合并在同一个工作岗位当中，但这并不代表这个岗位需要的就是一名所谓全栈程序员。这只能代表大家扩展了自己的专业知识，因此能够在更大的专业背景之下更好地完成工作。

请远离“全栈”诱惑。知道自己知道什么，也应该知道自己不知道什么。我很喜欢这句话，也在这里把它送给大家。“我不知道”，这是一句很有力量的话语。别再形势的压力下自欺欺人，否则最终的代价仍将落在我们自己身上。

作者介绍

Ted Gross，担任 CTO 多年，精通数据库技术、NodeJS、MongoDB、加密、PHP 和 OOP、虚拟世界技术和增强现实，曾在多个专业期刊和网站发表多篇关于技术的文章，特别是关于大数据和混沌理论的文章。此外，他还是文学小说、儿童读物和各种非小说类文章的作者，著有短篇小说集《古今传奇》。

原文链接

https://towardsdatascience.com/fullstack-programming-a-prelude-to-failure-2bc93cf19e71