全栈工程师：是救星还是杀手？
最近看到这一篇文章，我为什么说全栈正在杀死前端？说"全栈正在杀死前端"
全栈热潮下的问题
确实，现在很多公司打着"全栈"的旗号，其实就是想让一个人干两个人的活，却只给一个人半的工资。
我有个朋友小张，做了五年前端，技术很棒，连复杂的动画效果都能手写实现。去年他跳槽到一家创业公司，入职后才发现，老板期望他不但要做前端界面，还要负责后台接口、数据库设计甚至服务器部署。
半年后，我再见到他时，他疲惫地说："我现在天天在查SQL慢查询，调Docker配置，但最让我难受的是，我写的页面体验越来越差。以前我会为按钮点击反馈优化半天，现在只求功能能用就行。上周用户反馈说页面加载太慢，我明知道问题在哪，但没时间优化，因为老板着急要新功能。"
这不是个例。2017年，Facebook就吃过这个亏。他们当年追求快速迭代，让前端工程师同时负责后端开发，结果移动网页变得又卡又慢，用户投诉激增。后来扎克伯格不得不专门成立性能优化团队，花大价钱重新挽回用户体验。
但全栈真的这么可怕吗？
冷静想想，把所有问题都怪在"全栈"上，好像也不太公平。
我另一个朋友小李，在一家小公司做"全栈"，但他的情况完全不同。他说："因为我既懂前端又懂后端，所以我知道怎么设计API才能让页面加载更快；知道数据库怎么查才不会拖慢用户交互。上周我优化了一个商品列表页，不光改了前端代码，还调整了后端缓存策略，最终页面打开速度快了三倍。"
其实很多成功的产品，背后都有这种既懂前端又懂后端的人。比如Figma，这个在线设计工具刚推出时，很多大公司都不看好，觉得网页做设计工具肯定卡顿。但Figma的创始团队很小，每个人都既会前端又会后端，他们把精力集中在最影响体验的地方——实时协作功能，最终做出了连Adobe都紧张的产品。
真正的问题出在哪里？
仔细想想，问题不在于要不要学全栈，而在于我们学全栈的目的和方法。
我认识一位阿里P8级别的工程师，他说他团队里有两种全栈工程师：一种是"什么都会一点，但什么都不精"的，写前端代码像后端，写后端逻辑又像前端；另一种是"前端特别强，其他领域够用就行"的，这种人才是真正有价值的。
后者知道什么时候该专注前端，什么时候需要了解后端。比如他们知道怎么设计API才能减少页面白屏时间，但不会花大量时间研究数据库索引优化——那是DBA的工作。
找到平衡点
最近我看到一个挺好的例子。某家银行开发新App时，用了个小巧的技术方案：把大应用拆成很多小模块，像搭积木一样组合。前端工程师专注做好每个小模块的用户体验，后台工程师负责数据和接口。两者通过标准格式对接，互不干扰。
结果是，前端工程师不用再学复杂的服务器配置，能专注于让按钮点击更顺滑、页面加载更快；后端工程师也不用操心界面细节，专注提升系统稳定性。新App上线后，用户吐槽少了，开发效率反而提高了。
这让我想起一个老工程师跟我说的话："好木匠不一定非得会种树、会造锯子。他只需要知道什么木材适合做什么家具，锯子钝了知道找谁磨就行。"
未来到底需要什么样的工程师？
说实话，我不认为未来会要求所有工程师都成为"全栈"，但确实需要更多"懂协作"的人。
如果你是前端，没必要成为数据库专家，但应该知道基本的数据查询原理，这样和后端沟通时才不会鸡同鸭讲；
如果你是后端，不需要精通CSS动画，但应该理解前端加载数据的基本流程，这样设计API时才会考虑前端的实际需求。
我现在的做法是：保持前端专业能力的深度，同时有选择地学习其他领域知识。比如我知道Docker是什么、能干什么，但不会深入研究它的源码；我了解Node.js原理，但不会去争抢后端同事的工作。
最后想说
技术行业总喜欢制造各种概念和潮流，"全栈"只是其中之一。面对这些潮流，我们不必盲目追随，也不必完全抵制。
一个工程师最有价值的不是他会多少技术栈，而是他能否解决真实问题。用户不会关心你的按钮是用React还是Vue写的，他们只关心点击后有没有反应，页面加载快不快。
真正的专业，是在该专注时专注，在该协作时协作。与其纠结要不要做全栈，不如问问自己：今天我做的工作，真的让产品变得更好了吗？用户使用时，会不会感到一点点愉悦？
当你能回答"是"的时候，无论你自称前端、后端还是全栈，都已经不重要了。
