作者|赵云在这样的时代，不仅是老板，就连工程师都渴望成为全栈——创业公司或技术前沿行业招聘时，往往希望应聘者是全栈工程师.一份薪水，两种结果，面对这样的人才，老板们当然会“走运”！同样，相当一部分开发者，在职业生涯的某个阶段，也会开始寻求“全栈”的突破。原因通常是：可以加快自己的成长速度，希望以两倍的速度突破职场瓶颈，晋升到更高的职位。你看，如果说全栈的诞生是因为第一代技术栈“LAMP”太强大用不上的话，那么现在全栈的火爆可以说是两个原因：第一，为老板赚钱，二是程序员的归宿。1、全栈雷区迷信全栈是非常危险的。它的雷区是：今天所谓的前期节省会变成未来的成本：“变形”的数据库，大量的技术债要补偿，用户的困难描述愤怒的表情。图片来源：网络这就是为什么产品、开发、运维在沟通协作中明明各抒己见，但结果往往是“零零碎碎”：“这个产品的需求太变态了”“为什么那么多”很多安全限制》《运维要求》《服务器运行规范》我真的不懂》因为一个人做全栈非常难！自认为擅长多任务处理的人往往很糟糕，全栈工程成为一个关于“长期上下文切换”的生产故事。有这样一个多线程的典型问题——设计一个具有适当索引的BoyceCodd范式数据库模式，并实现一个高度可扩展的RESTful调用，同时构建一个直观简洁的用户界面来呈现与相应对象模型的交互？然后，支持和维护完整的实施以及在此过程中可能出现的任何问题。即使是有多年经验的老手，看到这里也可能会避而远之。原因是前端和后端一样复杂，两者都有自己的重点和做法。任何一个“结局”都需要经过多年的努力才能勉强做到。别忘了，每一个“端”都在与时俱进。对于没有经验的工程师来说，全栈工程并不适合，因为认知负荷超载会明显拖慢开发速度，导致更多错误，后患无穷。对于老手来说，全栈项目当时只能交出一份还过得去的答卷，过一段时间各种问题就会爆发。因为，只要一个领域继续快速发展，即使是经验丰富的工程师也很难跟上。尽管我们有许多天赋，但大脑并不是指数级的。在沉重的认知负荷下，人们不擅长多线程处理。2、为什么全栈只适合小项目？如果你在招聘软件中搜索“全栈”，你会发现招聘方要么是一家小公司，要么出现在前端工程师的职位要求中。难怪人们有一种固有印象，认为只有小公司才有全栈工程师。在这些组织中，需要高效的全栈工程。同样，早期初创公司在寻求资金时有时会满足于建立一个“松散”的MVP。（这很可能建立在服务器端渲染框架之上。）全栈工程师可以做到这一点，但他们不应该被利用或受到不公平的压力，因为初创公司无法雇用更深层次的团队。这里的关键是要擦亮眼睛，当一家公司赚到很多钱时，它需要从头开始重写代码。这不是重构或扩展营养不良的MVP的问题。该公司可能会将其丢弃，重新开始，并与合格的专业工程师团队一起将其构建得更加稳健。如果每个人都能接受全栈工程的局限性，愿意承担后果而不因代码库的不足而惩罚团队，那就让全栈“自由漫游”吧。对于软件工程中的一些问题，任何一个独立工作的全栈工程师都可以制定出可行的解决方案。通常有两种常见的用例：服务器端渲染框架攻击测试MVP或原型有些问题很熟悉也很简单，可以用服务器端渲染框架解决。RubyonRails、Django、Laravel...如果所需的解决方案完全适合这些框架，那么精通这些框架的经验丰富的全栈开发人员团队可以高效地构建。但请记住，虽然这只是为了满足短期需求，但大规模的复杂性和可行性存在上限。全栈开发人员致力于为一组众所周知的问题设计某些有限的选项。对于所有工程挑战，全栈并不是最优的。很可能在不久的将来，代码库将需要重构，以便迁移到适当规模的服务，或者实施更具创新性的方法来解决新问题。3、大厂没有全栈工程师？在大厂里，很少能看到一个工程师包着很多大橄榄。但是全栈人才不在少数。也就是说，大厂没有全栈项目，但全栈思维往往必不可少。这是因为高效的协作机制。以前后端沟通协作为例。后端开发人员可以专注于数据层、设计良好的RESTful端点、线程、可伸缩性问题、避免查询的n+1问题等等。前端开发人员可以专注于用户和应用程序之间愉快而直观的交互、高效的UI包下载以及精心设计和可重用的组件。每个人都可以独自完成大部分工作，完全专注于自己的专长，并善意地忽略对方的顾虑。但是，当他们的职责范围重叠时，团队成员会协作确定最佳解决方案。用户需要访问或编辑哪些数据？UI将如何调用API？数据合同是什么样的？团队围绕这些问题一起协调，然后处理他们自己的解决方案部分。通过将团队召集在一起进行这些对话，您确实可以在短时间内将流程减半，但一旦他们再次分开，您就会重新全力以赴，需要更快并正确地实现各自的功能职责。（与此同时，全栈工程师最多只能以一半的速度完成整个项目，多任务处理和上下文切换会使一切陷入困境。）正如您所预料的那样，鉴于这些重叠的职责，每个团队成员都必须了解其他专业领域。但是，如果专业知识不够深入也没关系，尤其是对于处于职业生涯初期的工程师而言。当然，并不是说大厂就没有全栈人才。相反，高水平的技术人员往往具有更强的全栈思维，在沟通和决策中起到关键作用。4.全栈需要合作精心打造。全栈不是灵丹妙药。只有合作才是成长的正途。在软件工程师职业生涯的早期，可能在其他职业中也是如此，有一种尝试一次学习所有内容的趋势。但现实总是打脸。按照一万小时定律，后端一万小时，前端一万小时，算法一万小时，运维一万小时……迟早要崩溃。想象一下尝试获得双博士学位。在数学和生物学中解决一个深层次的问题。随着你的注意力和时间的分散，你可能需要很多年才能完成这些博士学位中的一个。关键是，到那个时候，这个高深的问题已经被两个博士合作解决了，那就尴尬了。但如果两个人专攻术语，不时交流各自领域的研究进展，即使问题没有解决，也会找到解决的方向。软件工程也是如此。如果你决定长期专注于前端或后端工程，然后学会在不同专业的团队中很好地工作，你会进步得更快。这也是为什么一个团队的成员通常都会被安排成各有所长的原因。成员通过合作学习跨学科知识，跨学科知识将帮助成员解决更多问题。久而久之，团队成员将成为“主辅”的全栈人才。5.写在最后大多数情况下，对于企业来说，全栈只是一种选择，它允许工程师用有限的资源实现一个次优的解决方案。当然，也有一些例外，例如：特定用例中的特定工具，全栈工程师可以交付完美功能的代码。对于拥有多年经验的高级工程师来说，全面的专业知识可以合理地成为最后的选择。但不要把全栈当作灵丹妙药。不是解决所有问题。相反，它是解决某个领域的某些问题。因此，全栈思考问题的方式是值得肯定的。技术堆栈的层级发展如此迅速，以至于没有人可以控制一切。责任的多样化和专业化是自然的结果。所谓全栈，往往可以通过合作来更快更有效地实现，而不是仅仅学习。对于一个真正的全栈工程师来说，技术工作只是故事的一半。另一个关键部分是与其他团队建立一致的协作，以确保编写的代码符合他们系统的标准并实现一致的目标。参考链接：https://www.infoworld.com/article/3681896/full-stack-engineering-is-one-third-as-good.html
