在日常工作中，作为程序员可能会经常需要面对业务的变动和接受组织的工作安排，在不同的部门和业务下，我们所需要做的工作是不一样，那我们要如何尽可能快的上手一个业务系统呢？我在这简单聊聊自己的看法~

1.尽可能全地搜集项目资料

不论是转岗还是加入新团队，直接从事一个全新的项目机会比较罕见（尽管并非不可能）。大多数情况下，我们会接手别人留下的“遗产”。这无外乎几种情形：

1、前同事离职，你继承了他的部分工作；

2、或者你加入了一个新的项目组，被分配了特定的任务；

3、又或者领导对你青睐有加，除了原本职责外，还额外交付了一系列任务，附带了必要的文档。

所以在第一步，我们要去做的就是收集新项目的项目文档。就像学习一个中间件或者一门技术一样，文档就是一份说明书，有了说明书我们才能快速的去了解这个系统的概况甚至是细节。文档沉淀是我们在了解一个项目/业务的时候，最直接、便捷的方式。这也是为什么我觉得要把它放在第一位。

通常团队都会有一个新人空间，存放一些新人要看的基础资料信息，比如一些公共的平台、代码库地址、项目信息等等。这些可以帮我们了解一些项目的概况，一些基础能力依赖等等，但是这些对于我们来说可能还不太够。

我们还需要问带自己的师兄/组长（不同公司称谓可能不一样）要一些我们即将要接受的系统的详细资料。比如说：系统的架构设计、系统的领域划分、历史模块开发时候的设计文档 等等。即使不是自己之后可能负责的模块，有时间也要去阅读相关的文档，因为模块之间可能也会有一些相互依赖或者彼此支撑的关系存在。

不要不好意思开口去要，即使有点内敛的性格，也要“腼腆”的去要资料！因为我们了解的背景、相关领域知识越多，以后上手时候遇到的问题就会越少。不然可能后续需求或者什么来了，你发现什么模型我们都不清楚，那就会一步一坎。

2.梳理领域数据模型

我们在读文档的时候，不要只是简单的看看，有个印象就好，这对于我们接手一个项目是远远不够的。在这里抛个问题：我们阅读文档的根本目的是什么？（这个问题并不好，其实最根本的问题就是文章的标题 怎么尽可能快速地上手项目/业务？）

其实解决了这个问题，我们后续的工作就是顺藤摸瓜了。那我认为的问题的答案是什么呢？或者说问题的关键是什么？

这个关键问题就是 数据模型。

任何系统和业务的运作，不管是面向过程设计也好，面向对象设计也好，领域模型设计也好，其核心都是数据模型的设计。

单个数据模型自身的设计，比如：包含哪些属性、每个属性的含义是什么、这个模型本身代表什么等；同时也有数据模型之间关系的设计，比如：商品和SKU是1：n的关系，榜单和商品、商家等等模型是1：n的关系等。当然这里只是举个例子哈，具体问题具体分析。

我们在梳理数据模型的过程中，可以尝试画ER图或者其他图来把这些关系都表示出来，虽然画图的过程在外人眼里可能看起来会花里胡哨，但是只要帮助我们更好的理解和记忆这个模型这个系统，那就是一个不错的方法。我个人就喜欢边看文档边作图，这样即使后边忘记了，会过来翻一下之前的图例，就可以快速的回忆起来。

了解了业务系统内对应的数据模型，我们可以根据文档以及我们自己的理解，给他们划一下不同的领域，然后就可以找出来不同领域的哪些数据模型进行了交互，这样我们也就慢慢理解了业务里不同领域的范围。再到我们看代码的时候，我们对代码里的逻辑关系理解也可以更快更轻松。

3.理解项目结构及业务逻辑

在完成上述两步之后，我感觉我们就可以慢慢开始看代码了。因为我们已经理解了对应的数据模型，所以我们完全可以按照数据模型作为切入点，开始看项目。

一个项目，通常都会有不同的项目结构，比如说有的是MVC、有的是DDD，又或者其他。所以我们了解一个项目，首先肯定就是它的结构、模块（目录层级）上的划分。我们可以知道入口层在哪里、核心逻辑层在哪里、数据交互层在哪里、对外暴露的接口一般都定义在哪里等等这些项目的基础信息。了解了这些可以方便我们以后定位不同的代码在的位置，方便我们快速定位我们疑问的答案可能会出现在哪个目录（包）下。

之后我们就可以开始链路上的熟悉，参照我们之前搞出来的数据模型，我们可以逐个了解数据模型在系统内对应的业务逻辑设计/实现（这些在文档里或多或少也会提及，我们要对比着看），对于每个模块或者功能的业务流程，我们可以边看边作业务流程图来梳理。作图可以帮我们理清逻辑，也方便实在有看不懂的地方的时候，请教他人。

当然啦，遇到看不懂的流程也很正常，每个系统都会有很多新手不友好的内容。这时候不要害羞，还是那句话：“即使有点内敛的性格，也要“腼腆”的去要xxx”。我们可以去咨询负责对应业务的同学（一般根据文档的作者都能定位到），问一下我们的问题，然后记录下来。如此反复，了解系统的不同业务流程了解个七七八八（百分百肯定不可能的，后续还是需要通过实践来补充剩下的知识的）。

4.学习常用平台相关知识

在了解了差不多之后，我们就要开始为我们实战做准备了。

实战部分，通常会涉及到：需求的生命周期、项目的部署、开发模式（多分支开发、单分支开发）、中间件平台的使用、日志查询等等。

这些一般在新人文档中也应该会有，如果没有的话，就找自己的师兄问下（能找到肯定还是自己尽力找哈）。自己可以尝试搞个测试的分支，写一些测试的代码了解下中间件的使用、平台的使用等等，走个流程熟悉一下。

到这里，我感觉我们上手一个项目的准备基本上就差不多了，剩下的一些可能就要在实际项目需求中去学习了。

5.寄语与展望

本文呢，就是简单讲讲自己对于“怎么尽可能快地上手一个新业务/项目？”这个问题的理解，因为是从个人角度的理解写的，所以可能也会有一些遗漏或者和各位意见不一致的地方，大家有补充的或者指正的，欢迎评论~

希望这些建议能帮助我们快速适应新项目，实现个人和职业的成长！祝愿大家 bug--; money++;

来源  |  阿里云开发者公众号

作者  |  做棵大树