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

从去年入职字节到如今，已经有 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，固然单纯的交个朋友也欢迎啦。

文章首发于「三元同窗」公众号，欢迎关注。回复"JD"可得到职位描述，回复"IES"可进入「字节跳动 IES 预备招聘群」进群方式，你们一块儿学习、精进。