阅读 30922

神三元在抖音架构组的八个月,他经历了什么?

从去年入职字节到现在,已经有 8 个多月的时间了,今天来跟大家分享一下我的一些感受和想法吧。

之所以在这个时间点发出来,是因为我刚刚结束了自己的实习生涯,等今年毕业后再来的时候,就不再是实习生了。我觉得人生需要一些仪式感,我也需要一些时间来整理自己的想法,从繁忙、快节奏的工作当中脱身,去反思自己做的不好的地方,对过去这么长时间的经历做个总结,毕竟这样的机会真的不多。

我经历了什么?

初来乍到

刚来的时候,听说是抖音的架构团队,感觉很厉害。第一天见了 leader 之后,他告诉了我两件事,第一,每个程序员都有一个做架构的梦想,我还没毕业就加入了这样的架构组,得好好珍惜这里的机会;第二,这里做的事情基本上都是各种各样的挑战,会遇到很多困难,做好心理准备。

当时听完既欣喜又有点畏惧,能进入这样一个团队是多么酷的一件事情,但同时也担心自己水平和能力不够,接不了这个挑战。

怀着这样的心情,我加入到了第一个项目组,当时做公司的低代码平台,即通过拖拽生成网页的平台,当然在这块现在业内也有不少的实践了,技术复杂度不用说,肯定是相当高的。

当时有几个和我一起来实习的伙伴,入职了一周以后聊起来,他们说进了业务团队来了不到两天就开始接需求、提交代码了,但我还是空空如也,啥也没做,心理上难免有些落差。

中途我也找 leader 聊过自己的想法和困惑,他表示在这个团队当中前期上手的门槛会相较比较高,需要有一些耐心,同时也给了我很多开导,在感激的同时,我也深表赞同,打算沉下心来,继续熟悉项目。

但过了不久,我开始接触到团队当中其他的一些项目,看到团队当中也在做工程化脚手架相关的事情,正好之前在社区里接触过,比较感兴趣。想到自己还是处于实习阶段,为何不选择一个自己更感兴趣的方向去试一试呢?因此,我跟 leader 和当时的 mentor 表达了自己的想法,他们也很爽快的同意了。

还记得当时这个低代码平台只去了半个月了,后面转到了工程化方向,一待就是 8 个月的时间。刚开始转到这个方向,以为仅仅只是个脚手架,但 mentor 马上纠正了我,他告诉我这是一个庞大的工程体系,覆盖初始化开发调试CICD 等完整的开发流程,全面提升工程质量和工程效率。我当时一听,不明觉厉,甚至还有点小激动。(大家如对工程化的机会感兴趣的来找我私聊吧,这个组是真的很需要人,wx: sanyuan0704)

就这样,我开始了在工程化小组这边全新的征程。

渴望挑战

接下来一段时间的工作就比较顺利了,逐步上手了相关工具的开发,阅读了一些子模块的实现,并且写了近万字的源码解析被转到了部门群,也算是对新人培养体系的贡献。

mentor 经常安排一些小的功能让我去做,出了一些使用上的小 bug 也会让我去 fix 一下,文档方面需要完善的也会叫我去补(ban)充(yun)。接下来接近两个月的时间,基本是做这些。

这样零碎的事情做久了我也不太喜欢,虽然中间有一些挑战,但整体上并没有一个独自 own 的模块。中途找 leader 谈了谈自己的想法,也跟 mentor 交流了下后续的计划,我也理解他们其实是担心给我太难的工作我接不住,直接翻车了后果很严重。但面对即将到来的转正答辩,如果手头一个独自负责的模块都没有,都是些零碎的事情,未免有点捉襟见肘了,所以跟 mentor 说不妨给我安排一些可以独立负责的模块。

果然,提出我的想法之后,mentor 开始给我分一些比较大的模块了,我后面选择了其中一个作为答辩项目,是一个线上调试相关的工具,大概做了两个月,最后也顺利通过了答辩,拿到了还不错的 offer 评级。当然,在秋招当中,也直接接了字节的转正 offer。

专注深耕

答辩完回了一趟学校,那个时候还是 2020 年的 9 月份,再次回到字节的时候已经是 2021 年 1 月初了,大概请假了 4 个月的时间。可以说这是我第二段实习的经历了,相较于上一段经历而言,这一次实习的难度和压力都上升了好几次档次,遇到了相当多的挑战。

刚来的时候,mentor 给我私信,叫我去熟悉一下目前工程体系当中 SSR(服务端渲染)相关的内容,之前堆了很多需求,还有一些体验问题,没有人力跟进,现在要我把这部分承担起来。

说实话,面对 4000 多行的运行时框架,我不知道从何入手,连续看了两天源码没咋看明白,没想到第三天就接到 SSR 的新需求了,不禁让我感受到一种巨大的挑战。

刚来的第一周硬着头皮啃下来了大部分的细节,并且在周围大佬的指导下弄清楚了一些边界 case 的实现。

在做完之前堆积的一些 SSR 需求之后,mentor 跟我说目前的 SSR 是工程体系当中很重要的一个板块,需要好好思考一下,做一个长期的规划。于是,在那段时间当中,我逼着自己去调研了业内的许多 SSR 方案,包括Nextjsegg-react-ssrssr,包括公司内部的一些方案,也对SSGSPRESR做了一些研究。这个过程,既是在梳理未来的规划,也是在提升自己的视野,逐步进入技术的深水区。

之后我也一个人负责了 SSR 框架的 oncall(给使用这个框架的业务方答疑、解决 bug) 和新需求的迭代,按照预期的规划一步步推进,在建设 SSR 框架的同时,也对 SSR 技术本身有了更深入的理解。

咬牙坚持

本来想着可以全身心投入到 SSR 当中,但实际上却并非如此,由于我们的工程化框架需要落地到业务当中,于是 mentor 把我分配到了几条重要的业务线当中,作为 BP(即 Business Partner) 的角色去支持业务,没想到这些工作占据了我后期所有的人力,可以说中间困难重重。

首先是听说公司里面一个很重要的海外视频网站项目需要改造,日活是我做梦都想不到的级别,mentor 让我来负责改造的工作,改完了之后给业务方提个 MR(Merge Request),让他们合一下就可以。

但改造的过程比我想象中更加艰难,一方面我们组做的构建工具当中才刚刚封装完 Webpack5 的部分,并没有对外发稳定的版本,难免会踩坑或者遇到不支持的地方,这是内部的因素。另一方面,业务方对项目质量的把控非常严格,好不容易跑起来没有报错了,他们反馈说改造之后打包体积多了 20 几 KB (当时的完整打包体积是 500 多 KB),光优化这 20 几 KB 的体积,又得付诸好几天的时间和精力,最后才勉强达到他们的预期。

除了构建部分,后续又涉及到其他模块的改动,这里就不过多透露细节了。总而言之,是一个非常复杂的改造过程,中间有一段时间扎进项目当中,遇到了一些 block 的地方,也好几天睡不着觉。但改造结果还算成功,最后满足了业务方所有的需求,让那个日活上亿的海外产品跑起了我写的代码hhh(逃

接下来的一段经历是去做抖音的五一活动 BP,这也是我第一次参与到一线的业务开发当中,整体开发时间紧、强度高,大家一起坐在同一个封闭会议室,如同战友一般,Bug 一改就是一整天。在上线前的一个周,为了 Bug 日清,基本是每天凌晨以后才能下班。

虽然过程会比较辛苦,但真实地参与了一线业务开发的完整的过程,包括从需求评审、功能开发、与客户端/Server 端联调、QA 提测、反复众测、部署上线,更重要的是,看着自己的代码上线,被无数的人使用到,真的是一件颇有幸福感的事情!

工作后的感受

时间管理的挑战

尽管是实习生,但也是大小周,每天出勤的时间也跟正式工没有什么区别。工作以后给我最大的感受就是自己的时间被切得非常碎了,经常容易被各种事情打断,并且工作会占据自己绝大部分的时间,能够自己自由支配的时间可以说非常有限,像在学校里面什么都不管、闷头学东西的状态已经一去不复返了。

这就意味要想在这种环境下面保持学习的状态,就学会和碎片化的时间相处,学会合理规划和安排自己的时间。但其实我本身并不擅长时间管理,之前上学的时候能一个人能埋头钻研个好几天,现在没有了这种环境,所以有时候也会感到一筹莫展。

我跟大家一样,也有技术焦虑,每当看到一些新潮的工具框架、或者让我眼前一亮的技术,我都会想要去了解一下,但时常也因为时间和精力不够,学习的不够透彻,甚至过了一段时间就忘得差不多了。可能我们真应该想一想,是不是自己时间管理上出了问题?

其实我觉得时间管理本质上还是在于对精力的管理,如果不好好思考一下如何投入和规划自己的精力,每天被动地陷入一种常态的快节奏的工作模式,那么每天会浪费大量的时间而不自知,这是一件很可惜的事情。

架构组需要什么样的人?

待在架构组,与待在业务团队当中,对于工作能力的要求是非常不一样的。可能你会说了,这还用说,在架构团队当然对技术能力的要求更高啊。但从一个架构团队的内部视角出发,我想说的是,大家都忽略了一个很重要的事情,就是我们完完全全是靠自己在打磨一个个技术产品,注意,是产品。既然是做一个产品,那么就必须得经历需求分析用户界面设计产品功能设计代码开发、进行各种测试,那么就得通过一定的运营手段让产品被用户看到,最后达到用户的面前,交付给用户。

但是,这一切的一切,全由架构团队的开发人员自己来完成,也就是说,我们没有自己的 UI、没有自己的 PM、没有自己的 QA,一个人或者一个开发团队,就扮演了所有的角色。如果最后的技术产品出现了问题,肯定是中间某一个环节没有做到位,这个环节并非仅仅是技术本身的问题。

挺认同一个观点: 作为一个程序员,为了发展得更长远一些,最好需要懂一点 UI,懂一点产品,懂一点运营。坦白地讲,这些放在业务团队里面,其实是一个可选项,很多时候不懂也没有太大问题,有更专业的人给你 backup,万一 UI、体验做的不好,会有更专业的人给你指出来,也不需要操心什么运营推广的事情。但放到架构团队,几乎都是必备项,你得会站在业务的角度挖掘和分析需求,你得会设计符合用户使用习惯的工具和文档,你得会设计完备的测试用例保证技术产品的质量,你也得会向外人宣传、推广和落地自己的技术产品,这些都得你一个人做。

在架构组,带给我更多的是一种力不从心的感觉。因为我们做技术产品,对于我们开发人员本身的要求更加的全面和多元化,一个环节出了问题都是巨大的隐患,而且更重要的是,这些问题我们一般是后知后觉的。除非是使用的业务方抛出问题给我们,我们不会发现自己的文档还有这么多不清晰的地方,我们不会发现自己的测试用例都没写居然就把代码发布了(我先面壁思过)。

我们是能通过外界得到反馈,不管是 oncall 提问还是直接吐槽的方式,但这样导致的问题是,其一,如果作为架构团队的一员,真的是连最基本的产品意识和能力都缺乏,导致做出的工具漏洞百出,从而需要处理海量的 oncall 问题,这个维护成本是不是也在反过来抑制整个团队的产出,形成恶性循环?其二,如果用户觉得能用,但用的不舒服,不想反馈,是不是这样的问题就一直残留在我们的技术产品当中,而被我们给忽略掉了呢?看不见的问题,往往也是最致命的。

综上所述,是我觉得待在架构组感到力不从心的原因,当然也是我后续需要努力的方向,同时也是自己对这份工作岗位的一些理解。与其说团队需要的是技术大拿,不如说是需要把技术产品做好的人。

痛,并成长着

这一点就比较带有个人色彩了。坦白讲,一开始我是进去准备深耕 SSR 这块内容的,但后来被分配到业务当中,没想到会占用我那么多的精力,况且大部分时间都花在了业务项目本身。其实这是我不太愿意接受的,中途也因此心情非常糟糕,甚至和业务方大佬直接在群里开撕。但没办法,这个事情必须得做,而且也应该交给我做,因为换了人还得花很多时间熟悉业务,只会拖得更久。

工作以后,感觉很多时候我们是身不由己的,很多事情,即使不情愿,还是需要自己扛下来。这个事实我们无法改变,但我们可以改变的是看待它的视角

参加业务、熟悉业务的过程虽然给了我很大的心理负担,但这个过程中我看到了一个大型项目如何搭建脚手架、设计测试用例、搭建 e2e 测试环境、进行服务器性能压测等等实践经验,也参与到业务当中,如何做好埋点监控、降级容灾等等工程环节。这又何尝不是一种成长呢?过程看起来很辛苦,甚至是痛苦,但做完之后回过头看,才发现已经前进了很远了。

未来规划

你究竟想成为一个什么样的人?

这是我离开公司之前 mentor 跟我说的一句话,让我回去好好想想。我一时间想不出答案,也许这个问题还得围绕我很长时间,这里我暂且梳理一下之后的一些方向吧。

深耕专业技能

不管怎么说,当下最重要的事情还是提升自己的专业水平,不论是具体的技术栈,还是对架构设计的理解,我觉得都有很多地方需要加强。

曾经有一天我问旁边工作了很多年的大佬,你的 node 代码为什么写的那么漂亮?他的回答很简单:

多看多写就行了。

这不禁让我突然想起狼叔曾经也对尤大做过一个采访,他问尤大,你为什么能在 vue 中写出那么多巧妙的逻辑,而且把 git 当中那么多 tricky 的技巧用的得心应手,你是怎么做到的?尤大当时也是类似的回答,经常看开源项目,也许是专门抽出来的半小时,也许是喝下午茶的十分钟,不断从别人的项目当中学到编程思路,丰富自己的"武器库",日积月累,就可以渐渐提升自己的水平了。

让自己变得更加专业,设计出更加高质量的代码,需要很长时间踏实的积累,没有捷径可以走,如果非要说有捷径,那就是站在巨人的肩膀上,多看优秀的代码,从中获得一些想法,然后多动手来印证自己的想法。

加强时间管理

工作之后,才发现有效地管理自己的时间和精力是多么重要,而且如果不刻意地去改善,很容易被动地陷入到工作无尽的忙碌当中,难以脱身出来。

我觉得需要从两点着重入手,第一是学会做减法,以前什么都想碰一下、什么都想学一下的念头到现在是时候被舍弃掉了,有限的时间,需要被花在刀刃上,想做的事情太多反而会让自己分心,不如让自己集中在某些少量且重要的事情上。第二是提前做好规划,这样能充分利用碎片的时间,不至于漫无目的,闲下来不知道做啥而导致大量碎片的时间被白白浪费掉。

多输出、分享

过去一年输出、分享的频率明显降低了,一方面的确有工作繁忙的原因,但另一方面,也是因为自己本身的惰性,没有主动去思考和做计划。

我并不觉得这是一个很好的征兆。

毕竟之前和社区知名作者ssh聊过,很多技术水平很高的人是不怎么写文章搞分享的,但我们可以写出这么多的东西,并不是因为技术有多强,而是我们性格本身就是乐于分享的,而碰巧又有很多人喜欢我们分享的东西,给某些人带来了帮助,于是分享输出这个事情给我们附带了一些影响力

其次,作为一个原创的技术博主,我也深知输出就是一个倒逼输入的过程,比如写包管理器,以为看了官方文档就弄明白了,真正要写的时候才发现自己有那么多的知识盲点,npm 包管理的缺陷依赖安全问题社区的depedency-check 方案,这些都是我在写文章的过程中通过查阅资料一个个了解到的,之前甚至都没有涉猎过。所以输出的过程不仅仅是让读者受益,对于作者本身的知识体系也是一个锤炼拓展的过程。

一方面自己本身就乐于分享,另一方面分享也能倒逼学习和成长,所以我觉得这个事情很有必要坚持做下去。

最近关于工程化的输出正在逐渐变多,未来会更频繁地和大家见面,输出内容也会逐渐多元化,不再限于前端,也会包括自己工作当中的思考、读书心得(这些会放到公众号里面,掘金以技术输出为主),敬请期待吧。

关于团队

之前有很多读者对字节前端架构现在做的事情很感兴趣,我就先以自己目前所在的工程化团队来介绍一下吧。

团队工作涉及包括:

  • 基础工程化框架的建设,包含初始化、构建、调试体系、CI、CD,中后台研发框架(类似 umi)、以及代码质量相关的扫描平台
  • nodejs 基础库的建设
  • 可视化搭建平台的建设
  • 全公司资源分发平台的建设

团队的技术氛围还是挺不错的,虽然有的是异地办公,但在群里大家还是经常讨论分享一些技术方案,周会的时候也会经常有各个方向的技术分享。组里的技术大牛还是很多的,如果有问题,他们也会很耐心地帮你答疑解惑,通过和他们的共事也可以学到不少东西。

平心而论,团队现在还是相当缺人的,尤其是神三元同学现在所在的工程化框架的团队,我们也时常因为人力不够的问题而暂停了某些技术的进展(像之前说的 SSR 框架)。如果你对上面的这些方向也感兴趣,非常欢迎来和我们一起建设公司的明星级技术产品

最后我要强调的是,很多人和我聊的时候,我发现大家看到字节面试,就会下意识地觉得会出非常难的算法题,或者直接手写红黑树这种变态的编程题,这种看法是极端错误❌的!一方面是我现在的组并没有大家想象那么内卷,反而是团队搭建不久,更加需要新鲜的血液融入进来,出那种故意刁难候选人的题目压根没有任何意义;另一方面整个团队也是非常务实的,看重个人实实在在的工程能力和学习能力(潜力),那种跟平时工作八竿子打不着的问题我们也不会拿来为难候选人。

如果有意向或者对岗位还有疑问的话可以直接联系我,我的微信号是 sanyuan0704,当然单纯的交个朋友也欢迎啦。

文章首发于「三元同学」公众号,欢迎关注。回复"JD"可获得职位描述,回复"IES"可进入「字节跳动 IES 预备招聘群」进群方式,大家一起学习、精进。

文章分类
前端
文章标签