换组一年

去年的 11 月 1 日，我正式从原先团队架构下的 C 端换组来到了 B 端。在 B 端这整整一年的时间中感触颇深，我仿佛换了一家公司，工作流程、方式和沟通方式上有着巨大的改变，一改之前郁闷之像。

那些在 C 端的日子

在 C 端主要分为两个阶段，分别为头条和西瓜。在我校招入职时参与的是头条 app 上第二个底 tab 西瓜视频。当时从面试到入职前这一段时间里，与我对接的所有字节员工都打着“西瓜视频”的相关 title 来跟我聊，我下意识的当然认为“西瓜视频”一定就是我入职后将要负责参与研发的产品，然而我最终却做了半年的今日头条。这是最让我懵逼的一点，极其懵逼。

在 19 年下半年的那段时间里，我真的以为自己就要一直做头条里的西瓜视频了，虽说当时的头条 iOS 客户端 DAU 远超西瓜（现在依然如此），我却一点兴奋不起来，那种自己被欺骗的感觉久久在心中无法忘怀。好像你身边整个团队里所讨论的东西与你的日常夸张点说可以是毫无关系，头条和西瓜的工作流程、代码风格甚至开发合作模式宛如两家公司（现在早已不是如此）。头条上的西瓜不是头条的主业务，更不是西瓜的主业务，导致我后续做的绝大部分事情都是西瓜上的子集实现，这就让我更懵逼了，从产品层面上看虽然都叫“西瓜视频”，但这其中的差异大到我感觉自己与西瓜这个团队格格不入。

可能大部分人会更加喜欢做体量更大的产品，用户量越大自己就越开心，可惜我并不是这样。当然，没有人会拒绝自己的产品被更多的用户去使用，但我要表达的是，做一个产品绝对不是因为会被更多的人所使用而去做它，这因果关系是不一样的。我喜欢小而美的产品，那种你一打开会惊叹的由内心发出“哇喔”的赞美之词，越用下去越能感受到开发者通过这个产品所带给你他的想法，他所想表达的内容。这点从 18 年加入 vary app 开发组时的初衷是一样，vary 是我第一次发出“哇喔”的产品。因此，在负责体量如此庞大的头条 app 时，我没有丝毫的兴奋之意。一直到 20 年 3 月份团队业务发生调整时，我总算可以真真正正的去做西瓜 app 相关的事情了。刚开始我很开心，突然有一种名正言顺的感觉，终于可以不用当别人问起你在负责西瓜什么模块时，先打断对话说明情况“啊我负责的是头条上的西瓜视频，不是西瓜视频 app”。

但当我正式切入西瓜业务后，手上负责事情还没做完又被继续调整去做了当时令西瓜改头换面的“品牌升级”，这件事才是彻底击溃我的核心。刚开始知道自己要被拉去成立单独的开发小组，专门负责“品牌升级”的相关事宜，我又开始变得慌张，一是不想打破当时的状态，毕竟刚刚调整完业务，还没熟悉手上的事情；二是可能大家会很期待所谓的封闭开发，从个人角度去看这件事我是十分的抵制并反感的。封闭开发本质上就是把大家聚集在一起抹平在空间上的限制，快速响应，快速实施。但这就是问题所在，这一套流程下来正好就说明了日常的效率有多低，效率低到做一件事必须把大家都聚集在一起才能开展（细细品，可以说明很多问题）。

在做这件事的期间整个人已经麻痹了，甚至已经不知道自己为什么要加入这家公司。当初之所以加入这家公司加入这个团队冲的就是极强的技术氛围，可以刺激我学习到更多的东西，但每天被不同的事情压着，个人没有选择权，基本上就是照着 PRD 复刻一遍 UI 稿，如果有实验要求，你还要写两份甚至多份不同的 UI 表现，so why？我为什么要让自己去做这些事情，为什么要让自己的时间浪费在这种事情上？对自己的技术水平和业务水平毫无长进。刚开始确实兴趣很大，看着 PRD 中描述着只需要稍微改一改图标，调一调封面图尺寸，核心指标就会发生变化，仿佛自己宛如上帝一般可随意操控用户对某个事情的观感，但这种事情做多了以后会慢慢发现，你的意义就在于现在的你刚好有时间可以做这个事情，所以这个事情就交给你了。但这些事在 PM 和 UI 角度去看跟你完全不同，他们就是靠数据吃饭的，而你身为研发线，一定要做出一些对技术上的进步，但这些事情它就没法对你的技术上有进步，难道你要用五十六种语言来写五十六种 UI 吗？

在写绩效自评时，我看着过去自己做的这些事情到底对技术水平有多大帮助，能够写在自评里什么东西时，我茫然了……最后只能用一些“假大空”的话修饰自己做过的事情，这些加班加点把各种页面换了个样式的事情，除了让自己对这些 UI 修改点所在的代码位置有了更深入的了解以及在屎山上新增了更多的屎外，我是真没发觉这些事情到底能够给自己带来什么不一样的进步。关于加屎这件事当初我们封闭小组时非常不愿意做这件事的，小组长我记得非常清楚，多次跟 PM battle “如果你这么快就要，那我们的代码质量没法保证，带着 bug 上线”，令我感到惊讶的是 PM 居然同意了卧槽。一周一个需求 done 掉的感觉就像是每天要求你必须按时拉屎，拉不出来让你吃地瓜吃巴豆强行拉出来，而不是去给你诊断为什么拉不出来。日复一日我们的技术坚持也就没了，代码中写了大量的实验开关，就是因为担心后续上线时功能关不掉，而做这些东西让我们几个人不堪重负，坐我旁边的小姐姐那段时间几乎天天 10 半以后才下班。

所以在去年秋季绩效沟通时，抓住机会我直接说出了能不能换组的意愿，想要去做工具。我不想再忍受这种无意义的复刻，我只想有个正常的开发流程，能够正常的走完一个需求，让我可以静下心来好好的写写设计文档，考虑得更加周全一些。

这些在 B 端的成长

去年 11 月 1 日，借着团队整体工区搬迁之际，我正式更换到了西瓜 B 端，主要负责的事情就是西瓜上的视频剪辑器。当我得知这么快就可以换组就可以去做工具时，真的仿佛像是重新换了家公司。虽然这两个团队都挂在西瓜之下，但氛围、流程和技术都不在一个维度，可能你会问“为什么不换到基础技术组？”，我也不是没想过，首先我还是想跟用户近一些，做出来的东西用户能直接用到，我所感受到的就是用户所感受到的；其次是一想到还要跟之前的那一套打交道就十分的头疼，再也不想看到什么播放器、首页 feed 和详情页等等这一套东西了，就是想彻底离开这个环境，代码碰都不要碰。

我写了一份体验报告，对比了我在使用西瓜剪辑和其他剪辑工具的不同，包括优点和缺点，并且还给出了几个修复 MR，算是给团队做了一个不错的开头，后续团队的新同学入职都走了这个体验报告的流程。西瓜团队后续业务调整，B 端变为了“创作线”，C 端变为了“消费线”，我觉得是更加聚焦了，之前的 B 端仿佛就是做 toB 产品一般脱离了西瓜 app。现在经历了几个大的需求后，我原本以为会磨灭自己的热情，没想到自己热情反增不减，而且有越来越好的趋势。之所以会造成这种情况，好好想了一下，大多数原因其实就是自己在做事情的时候变得比以往更加专注，之前在消费侧时几乎每天都有在处理线上问题，因为代码量巨大，经过了无数人之手，部分看不懂的逻辑不知道做什么的代码删都不删，没有注释，commit log 只有短短的一个“update”就结束了，接口下发的数据一错，这些藏在犄角旮旯里的逻辑很有可能就冒出来了。而在创作线这边做的事情都是我非常喜欢的，能够极大发挥出自己客户端技术水平。

拿上一个小需求来说，支持导入本地音乐。这件事从名字上就可以看出是一个基础功能补齐的需求，但对应的 PRD 是个实习生，导致部分地方想得不够周全，这里不是批评实习生，而是说实习生只是因为对业务不太熟悉，导致一些关键点会遗漏。这个需求只有这位产品同学和我知道支持的导入方式音乐方式是咋样的，大家都默认以为在 QQ 音乐或者网易云音乐中缓存到本地的音乐可以直接通过这个功能导入到西瓜，但实际上却忘了 iOS 与 Android 的巨大不同，此时我们在其他音乐软件中缓存的音乐文件都是保存各自的 app 沙盒中，不像 Android 12 之前可以随意访问不同文件夹中的内容。还有一点是 apple music 中的缓存的内容也无法使用，因为 apple music 自己的流媒体数字音乐版权的保护，我们只能在 music app 中播放使用。那这音乐文件到底要如何导入到西瓜剪辑中去呢？有这么多种导入音乐的方式，而我们却选择了最麻烦最难用的一种，把你的设备插到电脑上，打开 itunes，拖入音乐，再打开西瓜剪辑对应入口就可以了。

这个流程让我用我是绝对不会用的，但这个功能有好过没有，我只是觉得缺了一角。做着做着我就提出了一个可以通过 share extension 的方式支持导入音乐文件，这样用户就可以相对之前的方式更加便利的使用 airdrop 或者文件分享的方式导入喜欢的音乐入西瓜剪辑。PM 都没想到可以这么做，我只能说用的太少，其次就是根本没想明白这个环节会劝退多少用户。我也做了相关的调研，也准备加入其中，但又因为种种原因无法考虑到整体的一致性导致通过 share extension 的方式导入音乐功能延期到二期需求中，而在字节的整体开发流程中，如果一期上不了的功能，会给你排到将近一个多月后的二期需求中，怎么说都感觉不妥。

也正是因为一二期需求时间差距过大，导致 PM 在提出一个需求，落地到 PRD 中时会尽可能的把关联细节都补上，又导致了一个需求上来周期会拉得非常长。有一个需求我从今年 6 月接手一直做到了 10 月中旬，这期间当然也在做其他的事情，但绝大多数的时间都被耗费在了这上面。这其实也看出了很多问题，我在创作侧的这一年时间里做的几个大需求都是时间跨度极长，也几乎都是从零开始搭建，最开始的模板到画中画再到智能挡脸，以及手上正在做的云草稿，每一个大需求我都是很兴奋的，在不停的刺激我多巴胺的分泌，但唯一的一点不好就是时间跨度真的很长。

这时间一长呢，很多大块的时间就很容易被小块的事情抢占走，导致沉淀也在慢慢变少，剪辑工具对客户端代码质量要求极高，因为上下游关联非常大，很有可能你的轨道元素其中的一个目标视频片段 id 写错了，那当用户在执行片段排序功能调整了不同片段之间的顺序时，原先片段下挂载的元素就都错乱了。最开始我在创作线上写的代码逻辑还是有很多考虑不周全的地方，导致出现了很多在几个边界 case 聚合在一起后才暴露出来的问题，不过这个情况也在慢慢弥补吧，随着对工程理解程度的深入现在再回过头去看之前写的代码逻辑，确实有很多问题。创作侧的技术氛围远超原先在消费侧的时候，因为创作侧并没有强依赖服务端，日常考虑的问题都是在如何精进客户端代码的健壮性，比如放开用户剪辑时长后，如何处理轨道多片段的卡顿问题、如何处理多 HDR 视频导出合成时的 OOM 问题等等，这些事情太让我感到兴奋了！

你要是问我加入字节加入西瓜对自身最大的改变是什么，我会告诉你我成为一个记录生活美好的 up 主，而加入创作侧以后，我成为了一名对视频内容有要求的 up 主，会主动去思考自己想要给观众看到什么内容，想要在画面中表现出什么东西，什么东西加入到视频中会更好，去除掉什么东西会更舒服等等，这些问题都是我在日常工作中慢慢积累起来的意识，这些意识都在不断的让我接收到新鲜的东西，不管是在视频创作的玩法上，还是视频内容本身的选择上，我都在慢慢的和工作内容相结合，这种感觉就像是你做了一个自己喜欢的功能给自己用，然后还有人给你发钱，绝！

但过去的一年时间里我没有输出什么有趣的技术内容，主要是在多媒体这个方向上我完完全全就是一个萌新，没有太多的内容可以说，一年过去了，慢慢的也成长起来了。最近也在做一个自己的视频剪辑器工程，之所以要做这个一部分原因是我看不惯为什么明明就是强依赖客户端能力的需求，却被底层 SDK 牵住了鼻子，我很不爽这一点。一个人脸识别算法对接了一个季度，连侧脸和半张脸都不支持，我实在是搞不懂外界传的字节算法很强到底强在哪。

总结

过去的这一年，自己改变很大，明确的知道了自己想要的到底是什么，尤其是当自己下定决定说出想要换组的意愿后，我感觉自己好像才是真的成长了，开始可以坚定的拒绝一些东西了。这点真的挺难得的，见过太多自陷其中无法自拔同学了，原因就是不敢走出那一步，如果哪一天在创作线我也失去了兴趣时，可能整个互联网行业我的兴趣也不在了。还是那句话，一定一定不要把自己的兴趣爱好变成工作，把兴趣爱好变成工作这是一个美好的童话，当初我也是这么以为的，但后来我差点放弃了这个兴趣爱好。我从未有过连续断掉这么多的 commit，这也说明了对写代码这件事在过去一年里是极大衰减的，兴趣爱好转移到了骑车上。

重新把这个兴趣爱好拉回来呢也是国庆假期期间彻底离开了北京，回家后呆的那段时间。一个人静静地想了很多事情，开始想起我当初加入这家公司选择这个行业的原因是什么，当初下定决心要换组的原因是什么，当初那么喜欢开源社区的原因是什么，当初养成了每天 commit 代码的习惯是为什么等等，这些问题我反复想了很多遍，最后才觉得在这个秋天重拾当初给了我人生极大转变的兴趣爱好——写代码，去做自己想做的事情，去颠覆掉自己认为不妥的地方，做一个自己喜欢的产品。