2023年4月，找到了自己的第一份工作，加入了上海爱用科技股份有限公司。当时在招聘的时候是作为前端开发工程师，结果进去之后变为了全栈开发工程。自此开启了自己的公司开发生活啦。
初进公司
在爱用的第一个项目是基于Taro开发的小程序，也是我第一次使用React+Taro进行小程序开发，当时由于是实习阶段，还在同时做自己的毕业论文，就用最快的速度进行开发了，中途倒是也没遇到啥难题。不过就是对代码结构过于放松了，对很多公用组件没有进行合适的封装，直接在各个页面中重复了。后面再代码提交进行review的时候被正毅指出，然后一个一个进行封装改写。真的很幸运，第一个带我的是爱用里对代码要求最严格的正毅，所以在后面一年的开发中，我都延续了当时的代码要求，每一个项目中的代码格式风格、代码复用性、结构化、可读性、鲁棒性都严格要求自己。(所以测试我需求的测试同学每一个人都说我的代码写得太好了，哈哈哈哈，根本不出问题，骄傲ing)
做完第一个小程序项目后，就进入了公司的代发项目组啦，然后在代发项目组中，就结识了贾佬、方师傅两个可爱的开发哥们。
代发生涯
什么是代发？
可能大家无法理解什么是代发，稍微解释一下：代发其实就是从低价平台，将商品复制到大家经常使用的购物平台。低价平台是什么呢？其实就是1688平台。购物平台呢？则是：淘宝、拼多多、抖店、快手、微店、视频号小店、小红书等。(所以大家买东西的时候可以多去1688上看看，上面很多都支持一件代发包邮，可以省钱 doge!)
加入代发项目组，可以说是幸运的，也可以说是不幸的。幸运的是在代发遇到了一群可爱的同事们，婉婷、贾佬、方师傅、大顺子，每一个人都非常的好，给予了我非常非常多的帮助。不幸的是代发项目组是整个公司业务最复杂、迭代最快、平台最多、任务最多的项目组，开发压力真的是公司最大的(当然对我来说其实也没啥感觉doge)。代发的任务通常是别的项目组的4-5倍的样子，而且由于接入的下游平台非常的多(8~10个)，各个平台的商品发布、订单处理、消息处理都不太相同，规则更新速度非常的频繁，所以需要了解的内容多到爆炸。而且有一个无论是在上班还是现在离职了都想疯狂吐槽的事情，代码太烂了，哈哈哈哈，实在是没眼看，没有注释、胡乱引用、单文件过5000行、没有技术文档等等。刚进入项目组的时候简直被折磨的死去活来。
代发前端
代发的前端平台有非常多的平台，其中包括：1688web端，1688手机端小程序，爱用代发，拼多多手机端小程序，抖店微应用等。所以在维护前端内容开发的时候就变得很麻烦，尤其是1688手机端小程序，这玩意恶心的不是一点两点，它是基于阿里内部开发的rap框架来进行开发的（其实就是对react做了层封装），是真的难用，每次改动都会触发应用的重新渲染，重新渲染也没事，主要这玩意他必须运行在虚拟机上，每次编译的时候存在卡死的情况，就得关闭虚拟机，重新打开。
而且在开发前端内容的过程中(这里特指web端)，代码结构混乱的可怕，redux的使用简直抽象，在一开始进行开发的时候，都无法对数据流进行判别，根本不知道数据是从哪里拿到的，完全是一团乱码。而且在对接口请求这块，简直是灾难，无法理解在一个页面中，会同时在初始化时，发起30~50个接口请求，导致页面在进入的时候直接空白等待很长时间(用户的脾气是真好，哈哈哈哈)。
就是在这种灾难般的开发环境中，我也开始进入到了代发助手王的日常迭代开发中去啦。不过好在适应能力比较好，基本也算是在很快的时间内融入了进去。前端内容的开发，如果不涉及到构建相关的，其实就是对着设计给出的设计稿进行复现还原，很难会有其他的需求(设计的博哥总是夸我是代发中前端复现最好的开发，每次开发完ui验收都挑不出毛病，非常的完美，哈哈哈哈)。
在整个代码前端开发中，感觉比较有挑战的就两块内容：
- 配合Aigc能力，实现前端的商品图片涂抹去除操作的画笔功能，这一块内容算是比较复杂的处理，还特地出了一篇文章来把部分原理阐述了一下(原文链接：juejin.cn/post/726069…)
- 抖店微应用开发。这块内容麻烦在哪里呢，就是整个前端组件库基本是我一个人搭建的，除了组件内容，还有redux的使用设计以及相关规范也是由我来进行指定的(感谢组里老哥们的信任)。然后其中非常复杂的两个模块：货品推荐页的前后端实现，订单页的前后端实现，都是由我复杂进行搭建的。
为什么说这两个页面非常复杂呢，因为里面涉及到非常多的交互内容，也是我们代发中最主要的两块内容了。尤其是订单，因为代发订单的特殊性，它实际是将上下游商品的订单进行同步，里面涉及到非常复杂的订单处理逻辑以及相关的状态对齐。然后就是由于在早前设计的订单数据实在是非常恶心，所以需要对订单数据在后端返回后进行处理，然后再传入特别多的展示组件中，非常非常麻烦。
（具体业务就不展开说了，涉及到前东家的还是不提啦）
代发后端
当然，前面说了自己进来公司后成为了全栈开发工程师，那么后端是跑不掉的。
在代发项目组，最开始使用的语言是PHP进行开发的。在今年年初的时候，项目开始进行部分搬迁，以及相关新功能也进行了搬迁，全部放在Node中了(nestjs框架)。
在代发后端中，其实没有什么特别困难的开发，但是由于之前人的开发习惯，导致很多东西维护起来非常的困难，尤其是在铺货模块（前人砍树，后人遭殃）。每一个平台的铺货模块都写在一个文件中，每一个文件都有6000~8000多的代码，让人无法理解的是还基本写在一个函数中，这……还有就是铺货的执行，居然是通过扫表的形式进行的，明明可以通过队列…….
什么是铺货？其实就是将1688商品复制到其他的购物平台中，这个是整个代发中最重要的模块之一，占据整个代发的一半的分量。这个模块后面也会出好几篇文章来具体讲，因为后面的整个铺货模块都是由我进行重构负责的，等于是俺背起了代发的半边天，哈哈哈哈。
当然除了铺货模块存在非常大的问题之外，订单部分也存在很多问题。因为在代发项目中，是存在关联货源的操作，所以可能用户铺货了一个商品，但是这一个商品在完成铺货的时候，可以关联多个商品，那么在产生订单后，发货时就可能需要进行多包裹发货，结果在这么多年里面，发货只有单包裹发货，不存在多包裹发货，这就导致了每周会出现相关订单发货反馈达到20~30个客户反馈，一直都没有人去修过……这还是最后我将订单发货模块全部重写了，才把这块内容完结掉，使其每月的客户反馈平均数量降到1以下。
多包裹发货内容，后面也会出一篇文章来好好说道说道，是真的很有意思的一个东西，里面牵扯到挺多处理逻辑的。
除了上述的问题外，后面还负责了一部分PHP项目迁移到Node服务中的担子。虽然这个由组内技术负责人先把整体框架搭建了，但是里面存在非常多的问题，在实际开发中也遇到了许多许多坑死人不偿命的内容，甚至导致了线上事故。后面也会出一篇文章来详细说说具体的问题。这里也可以列举一点：神策埋点重复初始化问题，在接口并发数超过3个时，会直接导致NodeJs服务直接重启；各开放平台接口调用存在问题等等。
铺货中台
说完代发的后端开发后，就是由我自己负责铺货中台服务了，这个项目建立的初衷就是将代发的铺货模块全部替换掉，因为老的存在维护性差、铺货成功率低下、正确性差、铺货时间过长等各种问题。那么为了彻底解决这些问题，只能通过重构。因为组里开发技术负责人的推荐，这个担子也就落在我头上了，然后就开启了痛苦与快乐并存的5个月。
这5个月内，不仅仅是将铺货中台完成了项目上线，还把原有的铺货前置和后置模块也全部进行重构，5个月内累计提交后端代码超过3.6万行。
虽然很疲惫(导致我后期都不想看到代码，犯恶心)，但是取得的成果非常非常的好。
- 淘宝(含淘宝、天猫、淘特)，成功率从41%提升至95%，正确性提升至99%，平均铺货时长从27秒提升至8秒。
- 抖店：创建商品接口调用成功率从43%提升至97%，商品发品成功率从39%提升至87%，平均铺货时长从26秒提升至7秒。
除了这些提升之外，服务器资源消耗减半，同时未出现过铺货堵塞情况，上述接入平台的每周用户反馈数量从30个下降至3个。上线后，稳定运行，每日铺货量达到50万+。
同样解释一下为什么是这两个平台先上线了，因为这两个平台的规则是最难处理的，同时用户数也是占到整个代发铺货的一半流量。
虽然上面取得的成绩非常好，但是由于各种原因最遗憾的就是没有将全部平台接入，这是因为一些个人的诉求没法得到满足，同时代发的策略倾向导向了卖货获取订单而不是在用户铺货上，铺货成为一个不受重视的模块（还有就是自己太累了，在这个项目中我一人分饰多角，无法得到人员倾斜和资源倾斜）。
这个模块的搭建和遇到的一些技术难题，后面会出大概3~5篇的文章来向大家进行讲述。
总结
在爱用的一年多时间，自己从一个前端转变成了一个全栈开发，不过比较幸运的是后端服务开发使用的还是NodeJs。在这一年多里面真的学习到了非常多的东西，也很感谢组里面的信任，让我承担起了那么多重要内容的改造和新项目的负责，让我从一个学生快速转变成了职场中人。虽然最后因为一些原因，无法继续一起合作下去了，但是真的非常感谢这段时光，感谢各位同事的支持。后面也要继续加油啊！
