来抖音架构组八个月，他怎么样了？

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

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

我经历了什么？

初来乍到

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

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

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

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

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

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

还记得当时这个低代码平台只去了半个月了，后面转到了工程化方向，一待就是 8 个月的时间。刚开始转到这个方向，以为仅仅只是个脚手架，但 mentor 马上纠正了我，他告诉我这是一个庞大的工程体系，覆盖初始化、开发、调试、CI、CD 等完整的开发流程，全面提升工程质量和工程效率。我当时一听，不明觉厉，甚至还有点小激动。（大家如对工程化的机会感兴趣的来找我私聊吧，这个组是真的很需要人，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 方案，包括Nextjs、egg-react-ssr、ssr，包括公司内部的一些方案，也对SSG、SPR、ESR做了一些研究。这个过程，既是在梳理未来的规划，也是在提升自己的视野，逐步进入技术的深水区。

之后我也一个人负责了 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，当然单纯的交个朋友也欢迎啦。

写在最后

谢谢你能读到这里。如果你觉得对自己有所帮助的话，欢迎点赞、在看、转发，非常感谢！