从工程师到全干工程师(上)#

入职#

2023年7月4日，我迎来了人生的新篇章。那天细雨绵绵，我早早地来到公司，怀着期待的心情等待入职培训。入职流程遵循着惯常的模式 - 培训、签合同、领取电脑。培训被安排在上午和下午两个时段，上午的培训结束后，各部门的leader会来接新人。我的leader是位中年人，鬓角已经泛白。初次见面时他给我留下了还算不错的印象，然而我并不知道，这只是噩梦的开始。

二手车索引#

作为新人，我的第一个任务是与两位同事一起为二手车建立索引系统。当我加入时，项目似乎还停留在起步阶段。两周后的一次"友好交流"中，领导指出我们的项目毫无进展。这个索引系统需要跨部门协作，但由于项目对其他部门没有直接价值，沟通变得异常困难。作为刚入职的新人，我心想这责任似乎不该由我来承担。

后来，领导提出了更务实的方案：基于实际线上查询需求来建立索引，而不是追求完美的全量索引。项目被分为两个阶段：处理存量数据和处理实时数据，同时需要严格把控运行时间和执行顺序。针对这个情况，我提出了一个优化方案：将两个阶段整合为一个统一的流程，把实时和离线数据的ID统一推送到消息队列，再由消费者根据ID查询原始数据并更新索引。这个方案不仅简化了流程，还巧妙地避开了时间和顺序的限制，只需确保同一ID由固定的消费者处理即可。

在项目实施过程中，我负责解析线上请求并提取需要建立索引的关键字段，同时开发离线和实时数据的ID采集模块，将这些ID推送至消息队列。另一位同事则专注于消费者端的开发，而第三位同事则处于辅助角色。虽然刚刚入职，但从被分配的工作来看，好像并没有被当做新人对待。

等索引的事情基本告一段落后，我就被安排至别的工作中了。

推荐系统#

转眼间一个月的时间过去了，被领导喊到会议室进行一对一沟通。按照惯例，先是一番话疗，随后他告知我将被分配到公共推荐场景项目中。所谓公共推荐场景，实际上就是APP首页的推荐系统，这是组里最核心的业务之一。我的第一个任务是负责样式组装服务，这个服务主要用于在推荐系统返回结果时，整合并组装客户端所需的各类字段信息。与此同时，还有一个创意服务，顾名思义，是为推荐内容生成吸引用户的创意信息。我接到的首要任务是将创意服务整合到样式组装服务中，将原本的RPC远程调用优化为本地调用，以减少维护系统数，削减维护代价。然而，没有人为我提供具体的实施方案，基于以往的工作经验，我决定采用最直接的方式 - 将创意服务的代码迁移到样式组装服务中。

这个代码迁移的过程并不复杂，但在测试阶段却遇到了不小的挑战。由于我刚刚接触这些系统，对其运行机制还不够了解，加上代码结构异常复杂，仅仅通过构造测试请求来验证系统的正确性变得异常困难。一次午餐期间，我与同事聊起这个困扰，他向我介绍了组里常用流量导流测试的方法 - 将线上的真实流量复制一份到测试机器上进行重放。这个技术让我眼前一亮，经过详细询问后得知这其实就是流量重放技术，使用的是开源的TCPCopy工具。在同事的指导下，我很快掌握了这个测试方法，完成了系统正确性验证。得益于公司完善的基础设施建设，上线过程也异常顺畅，只需要简单的几次点击操作即可完成。至此，我的第一个任务圆满完成。

大跌眼境#

随着对系统的深入了解，我逐渐发现了一些令人震惊的问题。有些函数的代码行数达到了惊人的2000行，更让人难以置信的是，甚至存在长达4000行的"巨型函数"。这是我第一次对公司的代码质量产生质疑。这些庞大的函数中充斥着数百甚至上千个条件分支判断，大部分都是为了兼容不同版本而存在的历史代码，让人完全无法理清其中的逻辑关系，同时还存在大量的僵尸代码，给人带来了严重的心理负担。虽然本着"能跑就不要动"的原则，我一开始也对这些代码持谨慎态度。

随着需求的不断迭代，我对系统的理解逐渐加深，也让我有了足够的信心来处理这些历史遗留问题。我开始着手清理这些代码，采用了一个科学的方法：首先从线上环境导出真实流量，然后利用JaCoCo代码覆盖率分析工具来识别未被使用的代码段。通过这种方式，我负责的项目代码覆盖率从最初的不到40%提升到了85%左右。在整个首页推荐项目中，我总共清理了超过3万行的僵尸代码。后来我了解到，这些冗余代码的来源是在之前的系统拆分过程中，当时的负责人采用了简单的代码复制方式，而没有清理不相关的部分。

得心应手#

随着时间推移，领导对我的工作能力越发信任，逐渐将更多的核心项目交到我手中。我先后接手了主体服务（负责协调用户兴趣分析、内容召回、排序等核心功能，并引入各种业务逻辑）、召回服务（基于用户兴趣从海量数据中筛选可能相关的内容）等重要系统。在首页推荐的8个核心系统中，我接触并负责了其中的6个，仅有用户兴趣服务和排序服务没有直接参与。通过负责如此多的关键系统，我对推荐系统的整体架构和运作机制有了全面而深入的理解。