1、全栈的雷区
迷信全栈很危险，它的雷区在于：今天所谓的前期节省，都将演变成日后的成本：“畸形”的数据库、一大堆待补偿的技术债务、用户难以描述的愤怒表情。
图源：网络
这也是为什么产品、开发、运维在沟通协作中明明各抒己见，得到的结果却往往是“鸡零狗碎”：
- “产品这个需求太变态了”
- “为什么有这么多安全限制”
- “运维要求的服务器操作规范实在看不懂”
因为一个人做到全栈，很难！
那些认为自己能很好地处理多任务的人，往往结果十分糟糕，而全栈工程就成了一个关于“长期上下文切换”的生产故事。有这样一个多线程的典型问题——设计一个具有适当索引的Boyce Codd范式数据库模式，并实现一个高度可扩展的RESTful调用，同时构建一个直观简洁的用户界面，以呈现与相应对象模型的交互？然后，支持并维护完整的实施以及过程中可能产生的所有问题。
即便是一个多年经验的老兵看到这些，可能都会退避三舍。
原因就在于，前端和后端同样复杂，二者都有自己的优先级和实践。任何一个“端”的精通都需要多年摸爬滚打，才能勉强做到。别忘了，每个“端”都在随着时代发生着演进。
于经验不足的工程师而言，全栈工程并不适合，因为认知负荷过载，会明显降低开发速度并导致更多错误，遗患无穷。而于老兵而言，全栈工程也仅仅能交出一份当时还算凑合得过去的答卷，过不了多久也会爆出种种问题。
因为，只要某个领域在继续快速发展，即使是经验丰富的工程师也难以跟上。
尽管我们有很多天赋，但大脑并不是指数级的。在繁重的认知负荷下，人们多线程处理的能力很差。
2、全栈为什么只适合小项目
如果你去招聘软件搜索“全栈”，就会发现要么招聘方是小公司，要么出现在前端工程师的岗位需求里。
这也难怪会让人产生一种固有的印象：只有小公司才有全栈工程师。
在这些组织内，高效的全栈工程是需求所在。同样，早期创业公司在寻求资金时，有时会满足于打造一个“松散”的MVP。（这很可能是建立在服务器端渲染框架上的。）全栈工程师可以做到这一点，但他们不应该因为初创公司无法聘请更深入的团队而被利用或受到不公平的压力。
这里的关键是要睁大眼睛，当公司获得大量资金时，就需要从头开始重写代码。这不是重构或扩展营养不良MVP的问题。公司很可能会扔掉它，重新开始，用一支合格的专业工程师团队更有力地构建它。
如果每个人都能接受全栈工程的局限性，并且愿意接受后果，而不会因为代码库的缺点而惩罚团队，那么就让全栈“自由漫游”吧。
对于一部分软件工程中存在的问题，任何独立工作的全栈工程师都可以制定出可行的解决方案。常见的通常有两种用例：
- 服务器端渲染框架
- 将MVP或原型进行攻击测试
有些问题很熟悉，而且很简单，可以用服务器端渲染框架来解决。Ruby on Rails、Django、Laravel……如果所需的解决方案完全符合这些框架，那么精通这些框架的经验丰富的全栈开发人员团队完全能够高效构建。
但请记住，虽然这仅仅可以满足短期需求，其复杂性和规模下的生存能力是有上限的。全栈开发者是致力于为一系列众所周知的问题，设计出某些有限的选择。
对于所有的工程挑战来说，全栈并不是最佳选择。很有可能会在不久的将来，就需要重构代码库，以便转移到合适大小的服务，或者实现一种更创新的方法来解决新问题。
3、大厂不配有全栈工程师？
在大厂，很少看到一位工程师大包大榄的情景。但全栈的人才不在少数。或者说，大厂不存在全栈工程，但全栈思维往往是必不可少的。这是因为有高效的协作机制。
以前后端沟通协作为例。
- 后端开发人员可以专注于数据层、设计良好的RESTful端点、线程、可伸缩性问题、避免查询的n+1问题等等。
- 前端开发人员可以专注于用户和应用程序之间愉快而直观的交互、高效的UI捆绑包下载以及设计良好且可重用的组件。
他们的大部分工作，每个人都可以独自完成，完全专注于自己的专业，并善意地忽视了对方的顾虑。但是，当他们的责任领域发生重叠时，团队成员协作确定最佳解决方案。
用户需要访问或编辑哪些数据？UI将如何调用API？数据合同是什么样子的？团队一起围绕这些问题进行协调，然后各自着手处理解决方案中各自的部分。
通过将团队召集在一起进行这些对话，确实会在短时间内将过程降到一半，但一旦他们再次分离，您就会回到全速状态，需要更快的速度并在各自的职责中正确实施功能。（同时，全栈工程师最多只能以一半的速度完成整个项目，多任务处理和上下文切换会让一切陷入困境。）
正如您所期望的，考虑到这些职责重叠，每个团队成员都必须了解对方的专业领域。但如果这方面的专业知识不够深入，特别是对于那些还处于职业生涯早期的工程师来说，这是可以的。
当然并不是说，大厂内部不存在全栈人才，相反往往高级别的技术人，他们的全栈思维更强，在沟通决策中发挥着关键的作用。
4、全栈需在合作中精心打造
全栈不是万金油。只有合作才是成长的正确路径。
在软件工程师的职业生涯早期，可能在其他职业中也有一种倾向，即尝试一次学习所有的东西。但现实总是啪啪打脸。根据1万小时定律，后端1万小时，前端1万小时，算法1万小时，运维1万小时……迟早会崩溃掉的。
想象一下，试图同时攻读数学和生物学双博士学位，去解决一个高深的问题。随着你的注意力和时间的分散，你甚至需要很多年才能完成其中一个博士学位。关键是，到那个时候，这个高深问题已经被两位博士合作解决了，那就尴尬了。但如果两个人术语有专攻，不时交流各自领域的研究进展，即便问题没有解决，也会发现解决的方向。
软件工程也是如此。如果你决定在很长一段时间内专注于前端或后端工程，然后学会在不同专业的人的团队中进行良好的合作，就会进步得更快。
一个团队的成员通常被安排得各有所长，原因就在于此。成员通过合作学到跨学科知识，而跨学科知识将帮助成员解决更多难题。
久而久之的积累，团队的成员就会变成“有主有辅”的全栈人才。
5、写在最后
在大多数情况下，于企业而言，全栈只是一种选择，可以让工程师资源有限的情况下，实现一个次优方案。当然，有一些例外，比如：特定用例中的特定工具，全栈工程师可以交付完美的功能代码。
而于拥有多年经验的高级工程师来说，全面的专业知识可以合理地成为一种最终选择。但不要把全栈当成万金油，它不是为了解决全部问题，相反，而是为了解决某一领域的确定问题。所以，全栈思考问题的方式是值得肯定的。
技术栈的各层发展十分迅速，没有人可以掌握一切。职责多样化和专业化是很自然的结果。所谓的全栈往往通过合作能够更快更有效的达成，而不是一味单干单学。
真正的全栈工程师，技术工作只是故事的一半。另一个关键部分是与其他团队建立一致的合作，以确保编写的代码符合他们系统的标准，完成一致的目标。
