2021 年还剩 2 个月，程序员如何在业务与技术中成长？

大家好，我是皮汤，是字节跳动今年的校招应届生。

在之前的 字节跳动的真实工作体验 中，我和大家聊了聊我在字节的头 6 个月，感受到的字节薪酬福利、工作节奏、成长与沉淀相关的内容。这篇文章收到了很多有意思的反馈，感谢很多朋友能够转发我的文章，如 ssh、启舰杂谈、菜鸟教程、秋风、三元，若川、还有可爱的***🐻，多亏他们的帮助，能够让我的文章被更多的人看到，也能与很多有意思的人成为朋友，同时也感谢程序员巴士的粉丝热情的转发与分享，让自己的亲朋好友也能够发现我，认识我 Thanks♪(･ω･)ﾉ。

而最近，整个工作、生活又有了很大的变化，首先是我刚刚参与了人生的头一次，在字节的工作绩效评估考核并且取得了还算不错的结果；其次就是字节教育进行了组织架构调整，而我与身边的同事们一同进入到了新业务部门，面对的业务场景与技术栈发生了很大的变化；所以关于本轮绩效周期的总结以及在 2021 年只剩下 2 个月的时间里，尝试对未来在业务、技术、团队发展方面做一个思考与展望。

字节跳动的薪酬理念

字节跳动倡导 “以能定级、以级定薪，以绩定奖”，每半年会对级别和薪酬做一次 review，相当于重新做一次招聘。正是这种高频率重新评估的节奏，有利于随时提醒自己不能停留在原地，需要不断的思考自身在业务、技术、团队中的位置，以及基于自己的能力加上努力的学习，自己能得到什么产出？

第一个绩效周期，本身我对这个评估方式、评估结果是没有预期的，只是想着能够去挑战一下自己的能力边界，所以跟随着时间做了很多次尝试，接下来我将与你详细聊一聊这些尝试。

工程师需要高效解决问题

我在字节的这半年主要负责 A 项目相关的业务开发与技术建设，尤记得正式入职一周拿到的第一个需求就是一个巨无霸需求，为 A 项目的题目编排提供完善的 PPT 相关能力的支持，包括可以新增多种元素：普通线框、图片、音频、视频节点等，然后可以在一个坐标系下，对这些节点进行操作，如组合、对齐、对齐线、吸附，还需要提供菜单栏和快捷键操作等来进行元素移动、层级调整。

值得一提的是，本来我可以将这个需求的大半都分给我的 mentor 去做，但是为了追求挑战自己，我主动承担了绝大部分需求。

拿到这个需求我的第一反应就是如何没有头绪，因为之前很长一段时间都是直接使用上层框架如 React、Vue，操作数据逻辑解决一些功能性问题，这次的需求显然需要下沉到 DOM 侧，需要对 DOM 操作、事件处理等方面有比较深刻的了解，而基于选中元素弹出菜单栏以及菜单栏执行一定的操作又涉及到 Web 的另一个活跃且高深的领域：编辑器。

身为一个刚入职的校招生，拿到一个细节极其复杂，且业务倒逼开发时间的需求，显然给我带来了巨大的压力。压力主要来自两点：第一我对排期没有什么概念，不知道这个需求到底几天可以搞完；第二就是这里面涉及到很多我遗忘的知识点，可能需要花很长一段时间去补齐这个方面的知识。

因为这个需求，我在刚入职的那两周，有很多天都是晚上 11 点多下班，甚至在快要交付的那几天，熬到了凌晨一点多，也一度因为这个熬出了痔疮。。（现在好了）

实际上一开始我是尝试从 0 开始恶补 DOM 相关的知识，甚至翻出来当前的圣经《JavaScript DOM 编程艺术》，但是看了 2-3 天发现光看书都要花一周多，实际排期又只排了两周，剩下一周开发完风险太大，于是就开始尝试第二条路子：找开源代码，于是祭出我多年修炼的代码查找功力，整理了好几个类似的项目，但是发现大多是 React 写的，而 Vue 写的功能又不完全和我的需求吻合，我们当时团队中后台项目绝大部分都是 Vue 技术栈，所以我有两种选择：1 是我把 React 项目代码看懂，然后用 Vue 实现一遍；2 是我看懂 Vue 项目代码，然后自己去解决剩下的问题。当时的我在面对这种抉择时没有什么可值得借鉴的经验，索性就硬着头皮先看起来。

一开始我尝试花了 2 天时间看懂 Vue 项目的代码，发现从现有的项目里去承接需求改造和新功能实现还有不少工作要做，于是我咬了咬牙继续看了 React 项目相关的代码，结果发现这两个项目之间共同点很多，可以很好的形成互补，而技术栈的切换其实并没有想象的那样困难，而绝大部分功能本质上思想是一致的，只是换了个不同的写法。随着看代码的深入，我开始理解了业务需求中实现需要的技术和思路。

有了现成的思路做支撑，加上我对功能需求的梳理，很快我便慢慢实现了这个需求，有惊无险的交付了这个需求。事后复盘之后我得出了一个道理，在拿到一个复杂需求时，不要要急着细究技术点，然后开始啃书，这样只会显得效率低下，解决问题能力低下；而是要学会调研现有市面上已有的项目、产品，然后研究他们的实现，参考前人的经验，站在巨人的肩膀上解决问题；通过这种方式，不仅学习了大牛在实际项目中如何使用 DOM 去处理复杂的功能需求的，还换了一种方式重新温习已经遗忘的知识。

工程师需要正确的解决问题

来到字节学习到的第二件事情就是工程师也需要洞悉业务痛点，需要使用最简单的办法解决看似复杂、多依赖问题。

尤记得工作过了 2 月有余，开始能够稳定的处理各种需求了，但是发现了一个奇怪的现象，我们维护的 A 项目经常会有 oncall（一种字节内部的反馈机制）反应图片相关的问题，尤其奇怪的是这个图片相关的功能我们使用内部提供的一种图片处理服务，按理来说不会出现问题。

这个图片服务目前已经商用了，详情参看火山引擎图片服务：veImageX。

这种图片问题的一种特征为 PNG 图片在上传之后，经过 veImageX 无损压缩处理会变大，What？压缩还会变大？我没有听错吧？

后续了解到 PNG 类的压缩算法，因 PNG 格式的差异，在无损压缩时确实存在变大的情况，大概会变大 2.4 倍左右。而这个图片变大对于注重体验的客户端来说是不可接受的，客户端强要求图片需要小于 100KB，但是我们之前因为流程问题本来对图片的限制就已经放宽到 150KB，而经过压缩变大之后，图片高达 300+ KB。

经过近一步分析，发现 6 条业务线都依赖于这个图片上传服务，从 A 中后台项目开始，经过 B 项目，然后将数据分发客户端，涉及三方，两个端（iOS 和 Android）、6条业务线，如果需要改造，那么是一个巨大的改造需求，耗时耗力，当时与产品交流大致预期 2 周开始逐步改造完成，并暂定撰写技术需求文档，走研发技术需求，需要 3 天之后向各端、各业务线进行需求宣讲。

本来这是一个艰巨的任务，但是我尝试思考，一个简单的功能影响面这么广，会不会有更好的解决方法？

于是我开始尝试找 veImageX 的 oncall，询问他们的开发者原因，然后结合自己不理解的点找到字节跳动前端大群咨询，广泛吸纳各方的意见帮助我进行判断，随着咨询的深入以及自己的上下文不断的补充，我觉得可以尝试从 “源头”：veImageX 服务提供方解决问题，那就是其实他们可以尝试做一个兜底操作，在对 PNG 进行无损压缩之后，如果体积大于原图，那么返回原图，最终就是两者去最小，这样我们业务方无论是中后台、还是客户端都不需要动任何逻辑，这个问题就自动解决了。

当构思好方案之后，我及时找到 veImageX 服务的开发人员，反馈我的想法，他们也欣然赞同了我的建议。就是这样一个小小的优化，从源头上思考问题，让我们大大减少了影响面，稳定了整个业务的迭代节奏。

工程师需要进行持续输出

如果你来到一家公司，就像你之前升学去到一所学校一样，你会有一个目标。在学校里你的目标是好好学习，拿到不错的成绩，考上不错的大学；在公司里，你的目标可能快速提高全方位能力，快速晋升，多拿奖金。

当然很多人可能是抱着学习文化，钻研技术来的，但绝大多数人应该都有快速晋升的想法。

而字节跳动有一个面向全体工程师的工程类研发能力模型，上面给定了各个职级需要的要求。通过这个能力模型，你能够认清你现在的位置，理解自己满足那些能力；同时你可以知道你晋升下一级需要什么样的能力与产出，相当于给定了你一个看得见、摸得着、可以做到的目标，这可能是激励无数工程师成长的动力之一。

对于我来说，想要晋升到下一个职级，显而易见需要从技术、业务、与团队方面进行全方位思考：

  • 技术上你可能是分享了一门新技术或有深度的技术见解，或是将一门技术从无到有落地，或是将一门技术从差到好升级
  • 业务上能够完成基本的业务迭代是本职工作，要善于从业务中发现产品、设计、研发、测试的问题，并尝试在改善产品、设计设计需求的体验，帮助测试快速且准确的完成测试，研发之间能够高效、顺滑的联调处着手
  • 团队方面你可以在团队的技术分享排期上进行合理安排，自身在分享时分享高质量内容，平时在做技术需求时多与其他成员交流或是带着成员一起去解决问题，或是尝试从 0 发起一个技术项目，然后找寻其他团队成员加入一起实现

上面的思考就是输出的一部分，你可以：

  • 输出自己在团队、业务上的思考
  • 输出自己技术文章

对于我来说，这半年主要在研究构建工具、组件库、WebAssembly 方向，也输出了很多不错的文章：

其中组件库方面的文章也受到了很多前端方面的朋友转载，感谢 零一、三元、世奇、LeviDing（丁丁）这些朋友的支持 💪（这里很多没有列全，但是都一并表达感谢 Thanks♪(･ω･)ﾉ）

持续输出的好处很多，不仅在团队内部可以为其他成员、为 Leader 留下深刻的印象，还能将这些文章发布对外，帮助到更多的人学习与成长，同时可以与其他一起做技术账号的朋友进行交流。

后续更多关于技术、业务、团队、认知提升的输出我也会在我的公众号：程序员巴士，上进行持续更新，欢迎感兴趣的朋友关注我的公众号❤️。

工程师需要带领团队成长

我在字节跳动成长的又一重大里程碑就是开始尝试带来团队去做一些事情，无论是偏向基建的，还是偏向技术项目的，还是偏向业务的，在尝试、实操之后发现，确实有一些经验可以值得分享。

“独行快，众行远”。一个人可以无所鼓励的快速跑步和调整，但是如果能够让一个团队也能够快速跑步和调整，那么将成倍于个人可以达到的水准。

在字节 6 个月的学习与工作里，最难的事情莫过于当你开始带团队去做一件事情的时候。自己做需求主要是接受安排，带团队是安排别人还要安排好，一个是舒适的循规蹈矩，一个是需要顾全大局，考虑到事情的方方面面，主要负责规划方案，安排时间节点，给出选择，大胆放权让团队其他人去自主挑选、自发完成，然后阶段性的检查完成进度。

如果你只是需求的开发者：

  • 拿一个实际的需求来说，例如开发一个涉及跨团队、包含前后端的需求时，如果你只是需求的开发者，那么你在实际需求评审、技术评审之前是不需要做过多思考的，可以按部就班的做自己的事情，等到实际评审的时候理清自己的开发边界，然后对好对应的接口，接着开始正常开发、提测就好。

但是如果这个需求你是 Owner：

  • 那么你需要在需求评审、技术评审之前，就开始主动与前端、后端、测试、产品沟通各方面上下文、排期相关的内容，然后整理一份完善的文档，并发给各方去看，继续补齐存在的细小问题
  • 同时你需要构思清楚整个需求的数据流向，在某个接口处需要的开发人员和涉及的依赖，这个接口处的需求他们该如何排期以至于不影响下一个接口的进度
  • 然后就是技术评审宣讲，接受来自各方人员的质疑还要能抗住不同的问题并提供解决方案
  • 接着就是开始开发，你需要去搭建属于你这边的开发框架，然后在时间点去检查其他接口人员的开发进度，如果有延期需要及时反馈
  • 开发完之后需要督促测试介入，产品验收，需求上到测试环境、灰度环境和生产环境等，直至整个需求的所有流程走完

其实你作为团队 Owner 的时候，就是你尝试将自己的经验、知识间接传授给组员的过程，帮助他们拆分任务、理解数据流动和各方依赖、辅助他们排期、检查他们的进度让他们对时间敏感、甚至是在组员搞不定时还要提供技术上的支持。这一过程也是带领团队成长的过程。

工程师需要创造需求与产品

如果说工程师要追求极致，那么那些表面上可以超脱工程类研发能力模型的东西可以尝试去做。比如并非公司官方指出的一些业务、技术与团队上的事情。

在字节的这 6 个月，我从零还是尝试打造教育前端的对外输出品牌：ELab，ELab 最初从微信公众号、掘金开始，目前扩展了知乎、字节内部的技术交流平台，输出了近 90 篇原创文章，单篇文章平均阅读 1000+。

ELab 平稳运行的背后是一整套完善的流程机制：

  • 一个较为完善的发展团队
  • 每周各团队进行文章收集、票选
  • 完善的奖励评比机制

合理分工、花长时间做思考、做有意义的事情，保持长期的耐心。在跑稳基础机制之后，ELab 寻求向上扩展上层建筑，目前已经举办了第一次 ELab 前端技术大会，未来会尝试开源专属的产品，并将技术大会打造成线下大规模会场的形式以及寻求文章内容多样性改进等。

ELab 本是一个在工作之余维护的项目，但是在进行深度思考之后，我产出了一套发展方案，并寻求 Leader 的支持与帮助引入了几位团队成员，并且长期坚持跑稳流程并作出一定程度的突破，横向拉齐教育前端的技术氛围和技术建设等。

业务调整，再思考

通过上述的在技术、业务、团队、创新性想法方面进行了一定程度的探索，不断挑战自我，追求极致之后，在 6 个月后的首次绩效评估中，我取得了不错的成绩。通过拿到不错的成绩来激励自己只是驱动因素之一，最重要的还是整个自我突破的过程：那些熬过的夜晚、埋头苦干的决心、思维认知的提升，以及在这个过程中认识的朋友、团队，更深刻的体会到字节的文化。我相信这些经历与成绩会成为我下一次绩效评估，或者接下来几年的职业发展打下一个很好的基础。

但是你可能永远也无法停留在原地品味自己过往的成绩，因为新一轮的挑战又接踵而至。整个教育业务在经过长达 2 个月的思考之后终于迎来了转型之路，从之前重投放、与 x 辅导、x 学堂之间的竞争转而全面沉下心来做产品，回到自己的初心和迭代节奏上来。

我们整个深圳团队都将调整至新的方向，开始从 0 到 1 建设新业务方向的技术、业务、团队方向的事宜。这意味着之前积累的所有业务方向的熟悉感都会清空，之前所有的前人的积累都将成为历史，你积累的各种业务中的人与交流经验也需要重新开始。

那么在 2021 年还剩下两个月，业务进行重新调整之后，一位校招生该如何思考和规划自己接下来的路呢？我这样问自己。

进行一段时间的思考之后，我心中已经有了答案。那就是依然坚持自己在过去六个月中学到的方法、高标准的要求自己：

  • 基于双月 OKR 对自己现阶段接下来的两个月要做的事情做一个总结，包括技术预研、业务理解、团队再发展和迭代方向分别产出一个规划
  • 及时在各个方向上找到对应的成员、负责人进行上下文拉齐，广泛阅读各种文档，打造自己的认知知识库
  • 技术上打算深入学习 WebAssembly 的相关知识，包括深入学习 Emscripten 编译器的知识、AssemblyScript 知识，以及 WebAssembly 底层的知识，能够产出一个将 C/C++ 项目 WebAssembly 化的高效方案；在小程序领域开始深耕，了解历史和各种框架，理解 Taro 的原理；同时对新的 Monrepo 方案如 Rush、完善的性能与监控方案的学习等
  • 开始尝试阅读字节跳动的历史文化手册、张一鸣的历史全员邮件，了解自己的发展历程
  • 开始尝试看一些书籍，包括《爱彼迎传》、《奈非文化手册》等，并且养成做笔记的好习惯
  • 尝试走出去，多与外面的大佬交流，与做公众号的大佬如 ssh、零一、若川交流，与搞创业的朋友 阿布 交流，与其他公司的朋友进行交流，交流技术、业务、团队、成长方面的思考
  • 多加入字节内部其他团队的群聊，了解他们的团队理念，进而反哺自身在团队建设上的思考

整装待发，再出发，持续迭代，再成长

当然在上一轮绩效周期中，我还有很多的不足，如：

  • 在技术项目上没有合理评估 ROI，导致有一些项目落地如 Vite 出了解决方案，但是落地方不多，收益不明显
  • 在技术、业务、团队建设上还有很多问题待解决，有必要找一些资深的业务负责人进行多交流，双周一次 One One
  • 同时在对事情进行数据分析、对内容产出进行图表说明等方面还有明显的短板

一个能够说明画图带来的好处可以很直观的看下面这张图，说明小程序的各方面性能指标的：

通过上图可以很清晰的看出整个小程序运行生命周期需要考虑那些指标，这就是画图的力量。

但是我相信深刻认识自我的问题，然后结合自己的规划，慢慢的解决他们，也是一种成长的过程。接下来的 2 个月，重新梳理一下心情，进入到下一轮发展与思考中去，像打造产品一样打造自我的能力，始终创业！

以上只是我在字节的 6 个月的绩效考核之后的一些总结与思考，同时也是我面对业务调整之后的一些规划和憧憬，我的经历如果对你有帮助，或者你觉得有一些更好的想法想要与我交流，都可以联系我的微信：hwwd8584 找我交流，或者关注我的公众号：程序员巴士，接收我更多关于编程经验、技术干货、职场思考的输出，共勉。