【快手转正】半年的风景：在代码与故事之间

前言：大家好，我是龙龙，于今年的5月8日加入主站研发线，作为前端活跃中。本文是对我所骄傲的三种业务的总结，也作为我这半年的回顾。

时间在键盘的敲击声中流逝。

六个月的转正周期，仿佛一次长途的迁徙，有起点，有迷雾，也有目的地。

回望来路，我像在浏览一条瀑布流：每个需求、每次提交、每一行注释，都是我画面中一帧帧的 Keyframe。

迁徙与漫游之间：面向用户的温度

第一个需求，是迁徙场景的改版。那时我还分不清文件夹的层级，那是一片陌生的海洋。是我最迷茫的时候。

改完第一处样式，我突然有点想笑，不是命令行里的 command，而是屏幕上那一点流动的光。

画面之后真的有人在旅行。

图1: 迁徙攻略要我半条命

迁徙卡片的改版让我第一次完整参与从视觉到交互的落地流程，也让我认识到“前端不是纯粹的展示层”。

多列与算法之间：寻找结构的秩序

双列瀑布流算法RefreshList是迁徙攻略的产物，几个月后继续迭代成为MCPage Module。如果说toC 业务是感性的前台，那么MCPage 就是“理性”的后台。那是一段深入框架的日子：树哥、小月姐、芸芝姐，我们研究双列的布局算法，设计了多列瀑布流的初代版本，并实现了下拉刷新逻辑。

一行行计算、一次次排序，像是在搭建一座透明的城市

卡片的位置、列的宽度、刷新时的节奏，

都在寻找一种看不见的平衡。

-- 我就像是一个施工队，保持上层建筑不倒塌的时候把地基改了，还要保证来回换地基的时候房子不塌。   6.24记

算法手稿：

图2：多列排序算法草稿

想象一下双列瀑布流算法，就是在给两根“时间线”同时堆方块：

1. RefreshList 先把一维的数据拆成一行两个的小组（[[item1,item2],[item3,item4]...]），每一行交给一个 Row 组件来渲染，然后在渲染时用 onLayout 把每张卡片的高度测出来，按行存进一个“身高记录本”（cardStyle + itemHeights），但注意：高度回调是乱序的，所以它用一个 updateQueue 保证永远按从上到下的顺序结算——前一行没算完，后一行乖乖排队。

1. 2. 具体排队规则是：先分出每行的“高个子”和“矮个子”，再结合上一行哪一侧更矮（minType）以及两列目前的高度差（offset），把高个子塞到短的那一列里，把矮个子放到另一边，同时用负的 top 把卡片“往上提”，刚好填平空隙，这样两列整体高度就始终你追我赶、不爆缝；行高则用 “本行高个子扣掉历史缝隙”和“矮个子高度”取最大值来决定。
2. 配合上拉加载、下拉刷新时对数据和布局的重新计算，这个算法本质上就是：用一条 FlatList + 一套按行结算的“身高对账系统”，在乱序的布局回调里强行排出一幅既紧凑、又平均、还不会闪白的双列瀑布流。

图3：双列算法渲染优化

Vision的小小世界：带来动效的灵魂

VISION是快手内部的动效工具，为设计师、开发者提供动效转码的地方。

Vision 的世界，是有光的。从 Keyframe 检测到动画帧率的调试，我像在雾里摸索电路。

那种混乱的美感，像是在深水里理线，直到有一天，逻辑忽然通透，脑子里闪过一阵风，屏幕亮了。

后来做图生码、做 Lottie 转 TSX，像是在看像素变成词语，看艺术重新变成可执行的语言。

在一次需求里，我用 AC 自动机代替了 Regex，学会在复杂世界中，找到自己那条更优的路径。

（突然想起 半年前决定来快手的时候，也说过类似的：每个选择都是局部最优解，谁知道哪边是最适合我们的呢？）

图5: 一些手稿

我第一次看到这么大的仓库，足足3个git。

这里我想和大家聊一聊AC，因为这是我第一次在这个大项目里中加入自己的想法～

那时小快和小6每天都在对着无数改动行发呆：

“小快，你看这一堆改动里，到底哪个才是 @effect 文件夹下的？”

“别问我，我已经用正则表达式到眼花了……”

我最初的做法就是靠正则，一个一个去匹配路径、文件名，再去 diff 文本里找特征。那时需求还小，这种方式挺香的。但后来情况完全变了，我们要在上万个 diff 里匹配上百、甚至上千个关键词。

于是，Aho–Corasick（简称 AC）登场了。它有点像是给小快造了一台“多线程放大镜”

把所有关键词预先织进一张巨大的网里，扫描一次就能把所有命中的词抓出来。以前每个 diff 都要跑上百次正则，现在一次扫描就全搞定。

图6：简单示意

尾声：递归中前行

半年我见过凌晨三点的屏幕光，

也在午后的会议室里沉默地听人讨论需求。

有人说工作像循环，我却觉得它更像递归：

每一次返回，都会带着一点新的变量。

我不知道下一个版本的我会是怎样的结构，

但我知道，在光标闪烁的地方，总有故事在发生。

而我，正在其中。

后记：这一路走来，我深刻知道我自己是幸运的。

这一路走来，深刻知道自己是幸运的。

导师 树哥 总愿意放下手头的工作，和我聊技术、讲思路。他的耐心与深度，是我心目中最厉害的代码高手。

我的 +1 在每一次 one-one 里都给我信心与方向，每当陷入疑惑时，君哥都能指一条明路（君哥的资源网站是真的多）。

小月 和 芸芝 会陪我加班改 bug（抱歉），小伙伴们（就不一一艾特午夜街溜子了）会一起吃饭帮我看 BUG。问过许多“看上去很蠢的问题”，但从未被谁轻视。

在校招培训时认识了很多好朋友，也因此结识了不少快手中学的伙伴（美美、安安、莹莹），培训结束后我们也保持联系。感谢快手中学始终给予的陪伴与资源支持，也感谢 简姐、佳姐 和 彩姐 的帮助。所谓“同路人”，就是在不同团队里，也能彼此点亮的人。

这半年来，不只是快手中学的关怀，在主站线内，也收获了无数帮助。

还记得第一天来时，是 假假 把我从会议室领出来。当时的心情还记得：期待中带着一点焦虑……但看到她时，焦虑就消失了一半，因为她笑得很开心。

感谢 HRBP 团队的 梅姐、彤姐 和 佳佳，他们给了我许多机会，也让我认识了很多大佬（梅姐的沉稳气质，够我学一辈子）。从小铁见面会到 AI First，无时无刻不在给予支持。

工作中，部门外的大佬们也一次次伸出援手。经常去 T11 五楼改 BUG，感谢业务线的 欣姐、宇哥、大龙、思宇 和 斯韵。大家不仅在项目中帮助我，也在平时维护中持续支持，还常常借我测试机，真好🥰。

Vision 的开发中更是如此。当我对 KDB、KConf 这些基建一头雾水时，是 鹏哥（他也是我的一面面试官）和 俊潮 以及师父的指引，让我迈出了第一步。

特别感谢 磊振 提供的 M0 支持——那像一张地图，把我从迷雾中带到结构清晰的地面上。上文提到的 AC 自动机也运行在 M0 的服务器上，这里特别感谢他们的帮助。

还要感谢 明昊 提供的容器、TK 支持，以及 鹏越 提供的 Hive 表支持。那时我连 Hive 是什么都不知道，是他帮我在服务中搭建了表，也让我在每次更新时都要麻烦他，真是不好意思。

很多算法的灵感，则来自 雅姗 的代码与她耐心的讲解，非常感激她的指导。

很抱歉无法将这一路上的朋友与老师一一列举。

最令我感到幸运的，是这里的氛围、这里的环境。从第一天开始，大家都会关心：新人是否能从 0 到 1 使用内部产品，是否遇到困难；而不会像我同学，只丢给 SOP 让人“自己悟呜”。。。