布景

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

在新部分作业2-3个月，由于种种原因，作业体会上的不同大到像是换了一家公司，也很想记录一下到底有什么不同。

纠结

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

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

1. Leader支持：和Leader沟经过，Leader觉得在咱们团队多做多学对个人，对团队都有好处，欢迎我斗胆测验
2. 后端同学支持：咱们团队的细分项目多，后端作业饱满，可以分一个相对独立的活给我
3. 全栈化布景：原先的大前端部分现已有部分前端转为全栈开发功能，部分层面鼓舞全栈化开展
4. 需求清晰：有些开发之所以忙碌是由于开会和对齐耗时太多。可是我现在拿到的prd都十分清晰，拿到就能直接开发，对齐扯皮的时刻几乎不计，我只需求完结开发作业即可。这节约了我很多时刻成本。想到之前常常是一天开个1-2小时会，搞得很疲乏。
5. 作业娴熟：从实习开始算起，我现已有2年多的开发经历，可以在预期时刻内完结需求开发和bugfix，因而安全的预留时刻精力转全栈。

其实不仅仅是我，和许多做前端的搭档、朋友也都聊过，其实内心各有各的纠结。基本上咱们的内心主意便是想在有限的条件下学习后端，并在有限的条件下承当一部分后端开发。

想学后端的原因：

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

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

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

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

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

不想学习后端的原因：

1. 国内商场上的全栈岗位数量稀疏，假如后端岗位有10个，前端岗位有3个，那么或许就只要1个全栈岗位
2. 普通前后端开发薪酬基本上没有区别，未来谁更好提升在当前的经济布景也难说
3. 大约率前端依然是自己的工作开展主线，学多一门技术或许会分摊本可以提升前端能力的时刻精力
4. 做舒适圈里边的工作很舒畅，谁知道多做会不会有好处

我便是在这种纠结中一路学过来，从8月开始，苦楚且挣扎，不过到现在为止还可以承受。学到现在甚至现已有点麻痹。但我也的确不知道继续在前端范畴还能专精什么技术，现有的事务没有那么大的应战性让我快速生长，所以想跳脱出来看看更大的世界。

学习道路

曲线学习

假如说做前端开发我是如虎添翼，那做后端开发便是常常呛到水。

记得我刚开始做前端实习的时分，真心感到前端知识如同黑洞，永远也学不完。由此十分佩服之前的搭档，怎样把这些代码写出来的，有些代码后面一看写的还不错，甚至或许会感觉脊背发凉，是自己太弱仍是自己太强？

在实习的时分，我的学习曲线可以说是一个向外分散的圆。比方我第一次接触webpack的时分，根本不了解这是什么工具，之前一向在用jQuery写项目，一切的js都是明文写好，然后经过script引进到html中。所以一开始我会去查这个webpack到底是什么内容，但脑海中对他的形象仍是十分含糊。接着我又由于webpack了解到了babel，css-loader这些概念，又去学习。又发现这需求利用到node，又去学习了《浅显易懂node.js》。再后来又了解到了sourcemap等概念。直到正式参加字节半年后，我自己配了一次webpack，而且阅览了他的源码。进行了debug，进行了一次webpack插件开发的共享，才有信心说自己是真的弄明白了。不过这个弄明白，也仅限于排查bug，配项目，进行plugin和loader的开发，假如遇到更难的范畴，那又将解锁一块黑洞。

怎样学

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

1. 怎样学 – 是死皮赖脸的逮住后端同学用力问，仍是多自己研讨研讨？遇到一切搭档都不会的问题怎样处理？
2. 学到什么程度 – 究竟要学到怎样的程度才能进入项目开发，而不犯下一些十分愚蠢的问题呢？
3. 学习次序 – 最简略的办法便是去看项目，看到不明白的分析一下这是什么模块的，看看要不要系统性的去了解。

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

比方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

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

脱离舒适圈，进入拉伸区，需求支付，需求勇气，也需求把握机遇。给自己多一种或许，去做，去应战自己不会的。我相信他山之石可以攻玉，越往深处走，就越能举一反三。