背景

我于22年校招入职字节安全方向大前端部门，支持公司安全Tob产品的前端开发工作。今年8月，因为组织架构调整，很多同事都直接划入了业务部门，我也和另一名北京的同事互换了业务，划入业务部门。

在新部门工作2-3个月，因为种种原因，工作体验上的差别大到像是换了一家公司，也很想记录一下到底有什么不同。

纠结

为什么要转全栈？究竟有什么收益？我会在心里时不时问自己这个问题。任何一门技能，从入门到精通，都需要很多时间的学习与实践，在初期都会经历一段相当痛苦的时光。除了学习不轻松，能否创造出更大的价值也是一个问号。

但这次转全栈，有天时地利人和的作用，总结下来就是：

1. 
   
2. Leader支持：和Leader沟通过，Leader觉得在我们团队多做多学对个人，对团队都有益处，欢迎我大胆尝试
   
3. 后端同学支持：我们团队的细分项目多，后端工作饱和，可以分一个相对独立的活给我
   
4. 全栈化背景：原先的大前端部门已经有部分前端转为全栈开发职能，部门层面鼓励全栈化发展
   
5. 需求清晰：有些开发之所以忙碌是因为开会和对齐耗时太多。但是我目前拿到的prd都非常清晰，拿到就能直接开发，对齐扯皮的时间几乎不计，我只需要完成开发工作即可。这节约了我大量时间成本。想到之前经常是一天开个1-2小时会，搞得很疲惫。
   
6. 工作熟练：从实习开始算起，我已经有2年多的开发经验，可以在预期时间内完成需求开发和bugfix，因此安全的预留时间精力转全栈。
   

其实不仅仅是我，和很多做前端的同事、朋友也都聊过，其实内心各有各的纠结。基本上大家的内心想法就是想在有限的条件下学习后端，并在有限的条件下承担一部分后端开发。

想学后端的原因：

1. 
   
2. 纯属好奇心，想研究一下后端技术栈
   
3. 前端作为最终的执行角色，话语权低
   
4. 业务参与度低，可以半游离业务的存在，较边缘化。未来如果希望成长为管理，难以做业务管理，只能做技术管理，想象空间天花板就是成为管理一批前端的技术管理。
   
5. 工作遇到天花板，想多了解一下其他的内容
   

想在有限条件下学习后端的原因：

1. 
   
2. 工作比较忙碌，没那么多时间学习
   
3. 学习一门技能要算ROI，学太多了如果既不能升职也不能加薪就没有意义
   
4. 不确定市场对于全栈人才的反应，不想all in
   

想承担一部分后端开发的原因：

1. 
   
2. 学习任何一门技能只有理论没有实践遗忘速度最快，马上就会回归到学习之前
   
3. 掌握后端技能但没有企业级实战经验，说服力很弱
   

不想学习后端的原因：

1. 
   
2. 国内市场上的全栈岗位数量稀少，如果后端岗位有10个，前端岗位有3个，那么可能就只有1个全栈岗位
   
3. 普通前后端开发薪酬基本上没有区别，未来谁更好晋升在当前的经济背景也难说
   
4. 大概率前端依然是自己的职业发展主线，学多一门技能可能会分摊本可以提升前端能力的时间精力
   
5. 做舒适圈里面的事情很舒服，谁知道多做会不会有好处
   

我就是在这种纠结中一路学过来，从8月开始，痛苦且挣扎，不过到目前为止还可以接受。学到现在甚至已经有点麻木。但我也确实不知道继续在前端领域还能专精什么技能，现有的业务没有那么大的挑战性让我快速成长，所以想跳脱出来看看更大的世界。

学习路线

曲线学习

如果说做前端开发我是如鱼得水，那做后端开发就是经常呛到水。

记得我刚开始做前端实习的时候，真心感到前端知识好像黑洞，永远也学不完。由此非常佩服之前的同事，怎么把这些代码写出来的，有些代码后面一看写的还不错，甚至可能会感觉脊背发凉，是自己太弱还是自己太强？

在实习的时候，我的学习曲线可以说是一个向外扩散的圆。比如我第一次接触webpack的时候，根本不了解这是什么工具，之前一直在用jQuery写项目，所有的js都是明文写好，然后通过script引入到html中。所以一开始我会去查这个webpack到底是什么内容，但脑海中对他的印象还是非常模糊。接着我又因为webpack了解到了babel，css-loader这些概念，又去学习。又发现这需要利用到node，又去学习了《深入浅出node.js》。再后来又了解到了sourcemap等概念。直到正式加入字节半年后，我自己配了一次webpack，并且阅读了他的源码。进行了debug，进行了一次webpack插件开发的分享，才有信心说自己是真的弄明白了。不过这个弄明白，也仅限于排查bug，配项目，进行plugin和loader的开发，如果遇到更难的领域，那又将解锁一块黑洞。

怎么学

学习后端，要学的内容也一点都不少，作为新人会遇到非常多的问题。

1. 
   
2. 怎么学 - 是死皮赖脸的逮住后端同学使劲问，还是多自己研究研究？遇到所有同事都不会的问题怎么处理？
   
3. 学到什么程度 - 究竟要学到怎样的程度才能进入项目开发，而不犯下一些非常愚蠢的问题呢？
   
4. 学习顺序 - 最简单的办法就是去看项目，看到不懂的分析一下这是什么模块的，看看要不要系统性的去了解。
   

我比较喜欢一开始就系统性的学，学完后再查缺补漏，再开启第二轮学习。

比如Go，官网就有很详细的文档，但未必适合新人去学。我跟着官网学了一阵子之后跑b站找视频学习了。然后又Google了一些资料，大致讲了一下反射、切片的原理，以及一些错误用法。学习Go大概用了2-3周。刚学完直接去看项目还是会觉得非常不适应，需要不断的让自己去阅读项目代码，找到Go的那种感觉。

然后需要学习很多公司内部的基建

• 
  
• 微服务架构 - 公司内部所有服务都是微服务架构，需要了解服务发现、服务治理、观测、鉴权这些基本概念以及大致的原理。为了在本地开发环境使用微服务，还需要在本地安装doas，用来获取psm的token。
  
• RDS - 公司内的项目分为了各种环境，非常复杂。可以自己先创建一个MySQL服务自测，看看公司的云平台提供了哪些能力。
  
• Redis - 大致了解即可，简单用不难
  
• RPC - 微服务通过RPC传递，RPC协议通过IDL来定义接口传输格式，像字节会在api管理平台做封装。你定义好的IDL可以直接生成一个gopkg上传到内部镜像，然后其他用户直接go get这个库就能调用你的服务。但如果你是node服务，就可以在本地通过字节云基建的工具库自动生成代码。
  
• Gorm - 所有的MySQL最终如果通过go程序调用，都需要经过gorm的封装，来避免一些安全问题。同时也可以规避一些低级错误。还需要了解gen怎么使用，将MySQL库的定义自动生成为orm代码。
  

还要好好学习一下MySQL的用法，这边花了一周看完了《MySQL必知必会》，然后去leetcode刷题。国庆节刷了大概80道MySQL的题目，很爽。从简单的查询，到连接、子查询、分组、聚合，再到比较复杂的窗口函数、CTE全刷了个遍，刷上瘾了。

接着就可以去看项目代码了，这一部分还是蛮折腾的，对于新人来说。本身阅读别人的代码，对于很多开发者来说就是一件痛苦的事情，何况是去阅读自己不熟悉的语言的别人的代码。

我最近接手的一个半废弃项目，就很离谱。开发者有的已经离职了，提交记录是三四年前的。PRD也找不全，到今天权限还没拿齐，明天再找人问问。这边可能是真的上下文就是要丢失的，没法找了。只能自己创建一个新的文档，把相关重点补充一下。

明天找一下这个项目的用户，演示一下怎么使用，然后根据对用法的理解进行开发……

收获

新鲜感

一直写前端真的有点腻，虽然现在技术还在迭代，但也万变不离其宗。而且真的是有点过分内卷了，像一个打包工具从webpack -> esbuild -> vite -> turbopack -> rspack。不可否认的是这些开发者的努力，为前端生态的繁荣做出了贡献。但对于很多业务来说，其实并没有太大的性能问题，对于这部分项目来说升级的收益很小。比如云服务的控制台，基本都是微前端架构，每个前端项目都非常小，就算用webpack热更新也不会慢。而且webpack使用下来是最稳定的，我现在的项目用的是vite，会存在样式引入顺序的问题，导致开发环境和生产环境的页面区别。

后端技术栈不管好还是不好，反正对我来说是很新鲜的。虽然我之前Python、Go也都用过，也用Python写出了完整的项目，但论企业级开发这算第一次~各方面都更正规

Go写起来很舒服，虽然写同样的需求代码量比TypeScript多一堆……习惯之后还是可以感受到Go的简单与安心。Go打包就没那么多事，你本地怎么跑服务器那边就怎么跑，不像前端可能碰到一堆兼容性问题。

真的有学到

我前几个月买了掘金大佬神说要有光的小课《Nest 通关秘籍》，据我了解我的几个同事也买了。不过我没坚持下来，因为工作上实在是没有使用到Nest的机会。我无法接受学了两三个月却无法在工作里做出产出的感觉。

但这一次学了可以立马去用，可以在工作中得到检验，可以接受用户的检验。我就会得到价值感与成就感。

而且字节的Go基建在我认知里很牛叉，一家以Go为主的大厂，养得起很多做基建的人。比如张金柱Gorm的作者，竟然就在字节，我前几天知道感觉牛人竟然……

Go的学习资料也非常多，还有很多实战的，真的像突然打开了新世界的大门~

与业务更近，以及更平和的心态

如果我没有学后端，会在“前端已死”的氛围里胡思乱想，忽略了前端的业务价值，前端依旧是很重要的岗位。让后端来写前端不是不行，但只有分工才能达到最高的效率。对于一个正常的业务团队来说，也完全没必要让后端去硬写前端，好几个后端配一个前端，也不是什么事。

就我目前的工作经验来看，后端可以和业务的使用者更近的对接。我们这里的后端开发会和非常多用户对接需求，了解他们的真实使用场景，思考他们背后的需求，可能还能弥补一下产品思考上的不周。和用户对齐数据传递、转换、存储、查询、以及需要不需要定时任务等等，这些后端会去负责。

而前端负责最终的交互，基本可以不用碰到使用者，基本上只需要根据后端给的接口文档，调用接口把内容渲染在表格上即可。碰到用户提反馈一般在于，加载慢（往往是数据请求很慢，但是用户会觉得是前端的问题）、交互不满意（交互美不美真的是一个很难量化的问题，按理说这属于UI的绩效）、数据请求失败（前后端接口对齐虽然体验越来越好，但是开发阶段经常改动还是免不了，最后导致前后端没有同步）。

之前开周会的时候，我基本上说不上什么话。一个是刚转岗，确实不熟。另一个是前端半游离于业务的状态，单纯的把接口内容渲染出来也很难有什么思考，导致开会比较尴尬。基本是后端在谈解决了什么oncall，解决了什么技术问题，有什么业务建设的思考等等。

这次看了别人代码之后非常期盼未来能独立owner一个方向，享受闭环一个小功能的乐趣。

职业安全感

我学的这项技能能够立马投入到工作中进行自我检验，因此我相信自己学的是“有效技能”。我理解的无效技能指学了用不上，然后忘了，花了很多时间精力最后不升职不加薪。之前看李运华大佬的网课《大厂晋升指南》里面有提到，有人花了半年把编译原理这个看似非常重要的计算机基础课学的很扎实，但因为业务不需要，不产生业务价值，也不可能获得提拔的机会。

其实内部全栈化我的理解，还有一个原因，那就是灵活调度。现在这个背景下，老板更希望用有限的人力去做更多事情。有些业务前端过剩了，但是缺后端，这个时候如果直接去招后端，一方面增加成本，再就是没有解决剩的前端，反之也是。在盘点hc的时候就容易出现调整。

多学一些有效技能，提高解决问题的深度、广度，让自己更值钱。我想不管是什么职能，最终都要回归到为业务服务的目标上。

End

写到这里，我依旧在转全栈的路上，只是想给自己一个阶段性的答案。

脱离舒适圈，进入拉伸区，需要付出，需要勇气，也需要把握机遇。给自己多一种可能，去做，去挑战自己不会的。我相信他山之石可以攻玉，越往深处走，就越能触类旁通。