如何尽可能快的上手一个业务or项目？

最近几年，大家都可以明显感受到IT行业的竞争压力和越来越严峻的形势。咱们作为程序员可能会经常需要面对业务的变动和接受组织的工作安排，又或者是自己主动选择跳槽/转岗到其他的不同岗位和部门。

在不同的部门和业务下，我们所需要做的工作是不一样，那我们要如何尽可能快的上手一个业务系统呢？大树在这简单聊聊自己的看法~

一、尽可能全的搜集项目资料

不论是转岗还是加入新团队，直接从事一个全新的项目机会比较罕见（尽管并非不可能）。大多数情况下，我们会接手别人留下的“遗产”。这无外乎几种情形：① 前同事离职，你继承了他的部分工作；② 或者你加入了一个新的项目组，被分配了特定的任务；③ 又或者领导对你青睐有加，除了原本职责外，还额外交付了一系列任务，附带了必要的文档。

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

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

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

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

二、梳理领域数据模型

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

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

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

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

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

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

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

三、理解项目结构及业务逻辑

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

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

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

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

四、学习常用平台相关知识

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

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

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

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

五、寄语与展望

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

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

觉得文章不错的，可以关注大树的公众号哟~

欢迎关注，一起进步