入职一家新公司以后

我保留着几份不同年份的入职记录。

最早的一份写于2014年。内容从安装系统、配置 Nginx、使用版本管理开始，几乎每学会一个命令都会记下来。后来入职另一家公司，笔记里开始出现开发流程、日志排查、消息队列和高并发。再往后，记录的重点变成业务历史、组织关系、系统边界和关键链路。

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

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

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

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

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

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

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

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

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

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

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

业务历史很重要。今天看似重复的两个系统，可能来自不同阶段的组织目标；一个难以理解的字段，也许曾经对应某个关键合作模式。忽略这些背景，很容易把历史形成的问题简单归因于前人的设计能力。

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

有些文档写的是设计目标，线上运行的却是经过多次调整后的版本；有些关键规则没有进入正式说明，只存在于团队成员的经验中。只读文档会得到一套整齐的系统，只读代码又容易迷失在细节里。

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

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

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

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

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

但现在再进入陌生环境，我不会急着证明自己已经看见问题。先理解一套系统为何如此运行，再判断哪些部分值得改变，通常比快速给出建议更重要。