入职一家新公司以后

我留着几份不同年份的入职记录，最早一份写于 2014 年，从安装系统、配置 Nginx 到版本管理，几乎每学会一个命令都会记下来。后来换工作，笔记里开始有开发流程、日志排查、消息队列和高并发，再往后则更多记业务历史、组织关系和系统链路。

这些变化不只是因为公司规模不同，也说明我对“熟悉一份工作”的理解发生了变化。

第一次入职：先让环境运行起来

第一次实习时，陌生的东西太多，很难判断什么最重要。

电脑环境需要配置，代码要从仓库拉取，需求通过项目管理工具流转，开发完成以后还要经历测试和上线。学校里写完能够运行的程序，只是公司软件开发流程中的一小段。

那时最迫切的目标，是让自己具备基本的工作能力。环境能够启动，知道去哪里查日志，理解任务怎样从提出走到上线，才有可能参与实际开发。

因此，笔记里保存了大量操作步骤。它们现在已经过时，却准确记录了当时面对工作的入口。

有了一些经验以后，入职新公司不再需要从基础工具学起。注意力会自然转向项目结构：有哪些服务，数据怎样流动，系统依赖谁，出现问题应该从哪里开始排查。

我曾经在刚入职时，根据代码和文档列出一系列改进建议。接口封装、配置方式、代码规范、监控和公共组件都能找到问题。

现在回看，那些观察不一定错，但下结论有些早。一个看起来不合理的设计，可能来自历史迁移、组织分工或当时的交付条件。只看代码，可以发现现象，却不一定理解为什么系统会变成这样。

进入更复杂的业务后，我逐渐把业务理解放在代码之前。

先弄清楚平台服务谁，价值怎样产生，业务经历过哪些阶段，主流程由哪些角色参与。然后再看这些概念如何映射到系统，哪些模块属于核心链路，哪些只是特定阶段留下的分支。

今天看似重复的两个系统，可能服务过不同阶段的组织目标，难以理解的字段也可能与过去某种合作方式有关。不知道这些背景，很容易把问题简单归到前人的设计能力上。

新员工通常从文档开始，但文档永远不够完整。

有些文档还停在设计阶段，线上已经改了几轮，也有些规则只存在于成员的经验里。只读文档容易漏掉实际变化，只读代码又容易陷在细节里。

更有效的方式，是带着一个真实流程交叉验证：用户完成一次核心操作会经过哪些系统，数据在哪里产生，异常怎样处理，最终由谁观察结果。沿着一条实际链路，文档、代码、监控和人的经验才能连接起来。

系统边界往往与组织边界相互影响。

哪个团队负责基础能力，发生故障时谁有决定权，一项改动需要哪些协作方，这些信息不会直接出现在代码中，却会决定项目怎样推进。

入职之初不必急着经营大量关系，但需要知道关键问题应该找谁，团队通常怎样做决定，以及哪些事情必须通过正式流程完成。

从工具、代码到业务和组织，我并没有找到一套适用于所有公司的固定方法。不同阶段仍然需要从不同位置进入。

现在再进入陌生环境，我会先了解实际流程和过去的选择，再判断要改什么，不急着把第一印象写成一份改造清单。