经过前后一个半月的努力在决赛圈做出决定，到入职这家公司已经半个月了。回顾这半个月的新公司历程，记录与思考下个人体验，这也是我作为软件工程师的第三段就职经历。
紧迫的入职窗口
接到 Offer 是星期一，HR 通知本周只剩下周三一天的选择窗口期，所有材料必须在周二下班前全部提交并审核通过，否则就要等下周集中办理入职。不过那样的话社保就要先中断一个月了，我是不太能接受的，于是抓紧时间准备材料，尤其是一天搞定了入职体检。
还有个插曲，第一个版本的 Offer 的试用期和转正后的薪资搞反了，还是我及时发现提醒 HR 修正的。
插曲毕竟都是插曲，只会让我的目标更清晰。
和之前的同事简单会了会后，星期三这天，我就正式开启了新旅程。
波澜不惊的第一天
因为允许员工使用个人电脑，我就把我新买的 ThinkBook 带了过去，用着新电脑体验新工作心情自然是很好的。工程师毕竟是知识工作者，适当愉悦才能最大化产出。其他同事估计也是这么认为的，架一台 Mac，搭配大显示器，再来个升降桌，或坐或立。
但也不完全像互联网公司一样弹性，没有本地的行政管理打卡是要严格遵守的，不过大家的状态切换很快。九点半大家不慌不忙的来到办公室，不到六点钟收拾好工作内容准备下班，期间就是高强度的密集工作。工作之外时间几乎不会被消息甚至电话打扰。
第一个上午我就是远程办理入职手续，企微与 OA 联系很方便，所有合同、手册都是线上查阅和签署，毕竟要协同多 base 地同事效率还不错。对于软件的使用自由度也比较好，全公司上千人大部分都是远程协同，允许自带电脑还不用安装深信服之类厂商开发的 DLP 软件，不会每时每刻监控员工的工作和聊天记录，也不会禁用 Sublime 这样高效的笔记软件。
主管和我主动沟通了试用期第一个月的工作目标和一些开发注意事项。这比我上一段工作经历有着更细分的工作职责，研发专注于开发产品，产品设计、市场调研、系统交付、项目管理等工作都有专职同事负责，更加体现了分工与协作的团队工作模式。
对于目标的设定，我不仅可以看到主管与部门的季度与年度目标，也可以看到其他架构团队的。同样，整个部门的产品代码仓库也是可以被共享的。
中午还想着可以和大家一起出去吃个饭，结果要么是有的回家去吃要么就是带饭的，没能如愿。我顺手把旁边有点脏的烧水壶桌面和微波炉桌面清理了下。休息期间几乎都是安静的，灯一关大部分人就支起躺椅进入午睡。
难说清的版本分支
第二天走上熟悉不少的上班路线，我早早到了。今天在通过产品说明书和测试环境了解基本功能外，接到了一个项目现场问题。
对于一个迭代四五年的产品来说，即使做了服务与模块切割也依然是体量不小的代码仓，更何况产品销售到了诸多省份。交付同事只跟我交代了组件版本，我翻到了十几个版本分支，简单比对了下分支差异都是有些许不同的，也都有持续的提交记录。
从问题的错误日志来看，就是一个接口入参的不同，一个是接收单对象，一个是传入了数组。对应着这些分支却发现都有所不同，有的是支持接收单个对象，有的是支持接收数组。刚接触新业务与新的研发管理团队，我的判断是不能简单归因，先解决问题。
兜兜转转几个人，最后找到了负责规划部署版本的同事，拿到了组件版本所属分支，复制修改，提交，验证，结束。
这里采用的也是主分支开发模式，然后基于特定项目拉分支开发部分不需要合并的特性。按照我的猜测，就会碰到项目版本开发的特性得到了良好反馈，又需要合并到主分支，可能还是部分特性拾取，合并过程又会融入其他产品经历纳入的新特性，结果就不言而喻了。这是工程难题。
更要命的是，没有单元测试。几个几十万行代码的项目都没有找到一个单元测试。修改代码需要启动整个工程，数据库、缓存、其他服务没有依赖的还好，这是花在环境搭建与配置上的。重构也变得艰难，没有测试保护的代码就像定时炸弹。最终就变成了跑得慢、改不动、读不懂的老爷车。看来，这又是一个工程问题。
也好，我似乎找到了用武之地，工程师就是在约束条件下系统解决问题的。
第一个需求实现
入职第三天，接到了第一个开发任务。我是怀着一些焦虑进入产品经理预定的视频会议中，大部分的业务术语或者行业术语我不仅不了解甚至还没听过。项目研发负责人敲定了两周完成时间，就下会了。
接下来的三天左右时间，我对照着产品文档和测试环境把相关模块梳理了一番，从页面功能、到关联接口、再到后端实现。能基本串联起业务流程后，我再和主管沟通下需要提供的帮助。也幸亏之前有参与过这块核心开发的同事没有全走完，能跟我讲下其中的「奥妙玄机」。软件开发就像一座水面上露出一角的冰山，冰山之下才是它的庞大身躯。
还好主管研发管理水平可以，没有让这些死角有太多存在，并适当清理技术债。每周一次的部门大会与小组会议，就是主动清除路障的好时机，没有让研发进度耽误产品业绩达成，也能投入精力照顾内部团队的精气神。
但对于像我一样的新人来说，加入团队开发飞轮的前提还是要通过一点一点啃代码来完成。虽然从知识学习视角来看，读代码是效率最低收益最慢的方式，但对于一个业务快速成长的团队来说没有比这个更好的，产品文档是跟不上软件开发速度的，也没有足够的规划或精力进行软件建模，那么只能通过一行行代码实现构建知识地图。
我又花了一两天顺着这些接口路径捋清楚他们的实现流程，对要实现的需求有了代码实现上的理解。这样，时间过去了将近一周。我可以找产品经理沟通聊细节了，看需求来源是否合理以及替代方案、是否会有影响面扩大的副作用、是否有没考虑到的业务细节新增等等。这在我第一段工作经历中是家常便饭，叫做需求答疑，一个产品迭代可能还会进行多次，几年过去它又回来了。
接下来两三天是继续深入实现细节，确认改动具体位置。看着动辄上百行的方法体、动辄上千行的动态 SQL 拼接，是考验耐心的。主管提前帮我识别到了技术难点，两个没有接触过的分布式数据库与 ORM 框架使用，但对我来说最大的难点是把已有代码看明白，既实现新需求又不影响老功能。
临近提交截止日期，我下了一个晚班，十一点多提交了最后一段自测发现的功能缺陷补丁。写了提测邮件，并附上整理好的开发说明文档，包括需求分析过程与产品已知问题、关联业务与接口改动、后端实现主体逻辑与影响功能、部署时序等。
没有比 Deadline 更好的生产力了。
