如何快速熟悉项目

1、什么叫熟悉项目？#

很多人理解的“熟悉项目”，就是把项目代码从头到尾看一遍。 但实际上，熟悉项目并不是把所有代码都看完，而是先建立对项目的整体认知。

简单来说，熟悉项目，就是让你尽快搞清楚下面这些问题：

• 这个项目是干什么的
• 这个项目用了哪些技术栈
• 这个项目的整体技术架构是什么
• 这个项目怎么启动、怎么运行
• 这个项目有哪些核心模块
• 核心业务流程是什么
• 关键数据存在哪些表里
• 功能是通过哪些接口完成的
• 一条业务链路大概是怎么走的
• 出问题的时候，应该先去哪里找

也就是说，熟悉项目的本质，是先在脑子里建立一张“项目地图”。

这张“项目地图”里，不只是代码，还包括：

• 业务地图
• 模块地图
• 数据地图
• 接口地图
• 技术栈地图
• 技术架构地图
• 启动与运行地图

2、为什么要熟悉项目？#

因为你入职之后，不可能一直停留在“把项目跑起来”这个阶段。 你很快就会碰到这些事情：

• 改需求
• 修 bug
• 联调接口
• 排查问题
• 写新接口
• 改老接口
• 查日志
• 跟前端、测试、产品沟通

如果你对项目没有整体认知，就很容易出现这些情况：

• 不知道从哪里开始改
• 不知道改完会影响哪里
• 不知道一个请求会走到哪些地方
• 不知道问题到底出在代码、配置、表、接口，还是中间件
• 不知道这个公司平时是怎么写接口、怎么组织代码的
• 看见 Redis、MQ、ES、注册中心、网关就发虚

所以，熟悉项目，不是为了学习而学习，而是为了后续真正开始干活。熟悉项目，最好有个文档输出，方便后续查询

1、先看项目是做什么的#

先回答下面几个问题：

• 这个系统是干什么的？
• 谁在使用这个系统？
• 核心业务流程是什么？
• 这个系统和其他系统是什么关系？
• 这个系统在整个业务链路里扮演什么角色？

常见了解方式

• 看 README
• 看 PRD / 需求文档
• 看原型图
• 让同事或导师先简单讲一遍业务流程

注意

不要觉得这些“不是代码，没啥用”。 很多时候，业务背景没搞清楚，后面你看接口、看表、看代码都会觉得每个字都认识，但不知道在干嘛。

2、再看项目用了哪些技术栈#

这一点非常重要，但很多新人容易忽略。

因为你后面能不能快速上手，很大程度上取决于你知不知道：

• 这个项目用了哪些技术
• 这些技术分别是做什么的
• 哪些技术你熟悉，哪些技术你不熟悉
• 这些技术在项目里分别是怎么用的

你要重点关注什么？

例如，一个项目里常见的技术栈可能有：

• Spring Boot
• Spring Cloud / Dubbo
• MyBatis / JPA
• MySQL
• Redis
• Kafka / RabbitMQ / RocketMQ
• Elasticsearch
• Nacos / Apollo
• XXL-Job / Quartz
• Docker
• Nginx
• 工作流引擎
• 对象存储
• 第三方支付 / 短信 / 邮件服务

你要先搞清楚：

• 这些技术分别是做什么的
• 项目里哪些地方在用
• 自己对哪些熟，哪些不熟

如果有不熟悉的技术栈怎么办？

不用一开始就把所有技术都学得很深，但至少要做到下面三点：

第一：知道它是干什么的

比如：

• Redis 是缓存
• MQ 是异步解耦
• ES 是搜索
• Nacos 是注册中心/配置中心
• XXL-Job 是定时任务调度

第二：知道项目里是怎么用它的

例如：

• Redis 缓存了什么数据
• MQ 在什么业务场景下发消息
• ES 搜索的是哪些内容
• 配置中心管理了哪些配置
• 定时任务在什么时候跑

第三：先参考现有代码，不要自己硬猜

如果你不熟某个技术栈，最实用的方法通常不是先啃一堆理论，而是：

先看项目里别人是怎么使用这个技术栈的。

这样你后面真正需要改或者写的时候，就不会太心虚。

你要建立一个意识

熟悉项目里的技术栈，不是为了炫技，而是为了后续需要改到这些地方时，能快速看懂、快速参考、快速上手。

3、再看项目的整体技术架构#

除了知道用了哪些技术栈，还要知道这些技术栈是怎么组合起来的。

也就是要搞清楚：

• 这是单体项目还是微服务项目
• 请求是怎么进来的
• 服务之间怎么调用
• 数据库、缓存、MQ、搜索、中间件分别放在什么位置
• 网关、注册中心、配置中心有没有用
• 系统的主要链路是什么

你可以从这些角度去看

• 项目目录结构
• 服务拆分情况
• 系统架构图
• 部署文档
• Nacos / 注册中心里的服务列表
• 网关配置
• README / Wiki 里的架构说明

你至少要搞清楚这些问题

• 用户请求先到哪里？
• 是直接进应用，还是先过网关 / Nginx？
• 服务之间是 HTTP 调用还是 RPC 调用？
• 数据是落 MySQL、Redis 还是 ES？
• 异步流程是不是通过 MQ 处理？
• 定时任务有没有参与业务流程？

为什么这一步重要？

因为很多时候你不是不会写代码，而是你根本不知道：

这个功能在系统整体链路里是怎么流转的。

技术架构一旦看不清，你后面就很容易出现：

• 只看到自己眼前这一个服务
• 不知道为什么改了这里，别的系统也受影响
• 不知道问题到底出在网关、服务、缓存、消息还是数据库

4、再看项目怎么启动、怎么运行#

这一点也非常关键。 因为“项目怎么启动”，其实直接决定了你能不能开始真正熟悉项目。

你至少要搞清楚这些：

• 启动类在哪
• 项目是单服务启动，还是多个服务配合启动
• 本地启动需要哪些依赖
• 依赖哪些中间件（MySQL、Redis、MQ、ES、Nacos 等）
• 配置文件在哪
• 不同环境配置怎么区分
• 启动失败时日志在哪看
• 启动之后怎么验证服务是正常的

你要重点看什么？

1）启动方式

比如：

• 直接运行 Spring Boot 启动类
• 先启动注册中心/配置中心，再启动服务
• 需要先启动数据库、Redis、MQ
• 需要 Docker / docker-compose 辅助启动部分依赖

2）运行依赖

比如项目启动前，是否依赖：

• MySQL
• Redis
• Nacos
• Kafka / RabbitMQ
• Elasticsearch
• 第三方接口配置

3）环境配置

比如：

• application.yml
• application-dev.yml
• bootstrap.yml
• Nacos / Apollo 配置

你要知道：

• 本地启动读哪个环境
• 测试环境和本地环境有什么区别
• 哪些配置改错了会导致项目根本跑不起来

为什么这一步重要？

因为很多新人虽然能“勉强把项目跑起来”，但其实并不知道：

• 为什么要先启动这些依赖
• 为什么这个配置放在这里
• 为什么这个服务必须连到那个中间件
• 为什么本地跑得起来，测试环境不一定跑得起来

所以，熟悉启动方式，本质上也是在熟悉项目的运行机制。

5、再看项目有哪些模块#

你要先搞清楚这个项目是怎么拆分的。

比如一个项目里可能有：

• 用户模块
• 订单模块
• 商品模块
• 支付模块
• 权限模块
• 公共模块

你至少要先知道：

• 项目有哪些模块
• 每个模块是干什么的
• 哪些是核心模块
• 哪些是边缘模块
• 模块之间大概怎么调用

常见查看方式

• 看项目目录结构
• 看 Maven / Gradle 多模块配置
• 看服务注册中心（如果是微服务）
• 问同事“平时最常改的是哪些模块”

建议

一开始先重点熟悉 最核心的 1~2 个模块，不要想着一下把所有模块都吃透。

6、再看核心表#

对于后端来说，数据表是非常重要的切入口。 因为：

数据是业务在系统中的投影。

有时候你先看表，比先看代码更容易理解业务。

看表时重点看什么？

• 表名
• 主键
• 业务字段
• 状态字段
• 关联字段
• 时间字段
• 索引字段

推荐做法

1. 先找 3~5 张核心表
2. 理清这些表之间的关系
3. 查几条真实数据看看
4. 再去对照代码中的 Entity、Mapper、Service

举例

假设你在看订单系统：

• user
• order
• order_item
• product
• payment_record

你只要把这几张表的大概关系看明白，对业务整体就会有一个比较直观的理解。

7、再看核心接口#

很多新人熟悉项目的时候，会忽略接口这一层，直接看代码。 其实，接口是后端开发最重要的业务入口之一。

因为大多数业务流程，本质上都是：

1
前端/其他系统发请求
2
        ↓
3
接口接收参数
4
        ↓
5
后端处理业务逻辑
6
        ↓
7
查询/修改数据库
8
        ↓
9
返回结果

所以，熟悉接口有两个目的：

第一个目的：了解系统有哪些功能入口

通过接口，你可以更快看懂：

• 系统提供了哪些功能
• 一个功能通常是通过哪个接口完成的
• 接口和表、代码、业务逻辑是怎么对应起来的

第二个目的：了解这个项目平时怎么写接口

这个非常重要。 因为你后面自己写接口时，不是随便按自己习惯写，而是要按照项目现有规范来写。

你要通过熟悉接口，总结出这个项目的接口风格，比如：

• URL 怎么命名
• GET / POST / PUT / DELETE 怎么用
• 请求参数怎么封装
• 返回结构怎么统一
• 错误码怎么定义
• 分页怎么写
• 模糊查询怎么做
• 参数校验怎么做
• 鉴权怎么做
• 接口文档/注释怎么写
• 异常处理怎么做

也就是说：

熟悉接口，不只是为了知道系统有哪些功能，更是为了总结这个项目写接口的规范和风格，方便后续自己按照统一方式开发接口。

看接口时重点看什么？

• 接口路径
• 请求方式
• 请求参数
• 响应结构
• 错误码
• 分页参数
• 是否需要登录态/鉴权
• 这个接口会影响哪些表
• 这个接口最终会走到哪个 Controller / Service

建议

先看 3~5 个核心接口，例如：

• 登录接口
• 列表查询接口
• 详情接口
• 创建接口
• 修改接口
• 提交 / 审核 / 支付这类关键动作接口

最推荐的方式

• 先看 Swagger / Knife4j / Postman
• 再实际调一次接口
• 最后顺着接口去看代码

1、最常见的看法：从接口开始追#

以一个创建订单接口为例：

1
OrderController.createOrder()
2
        ↓
3
OrderService.createOrder()
4
        ↓
5
参数校验 / 业务校验 / 库存校验
6
        ↓
7
OrderMapper.insert()
8
        ↓
9
写订单表、订单明细表
10
        ↓
11
返回结果

你要顺着这条线去看：

• Controller 做了什么
• Service 做了什么
• Mapper / DAO 做了什么
• 哪些表被查了、被改了
• 日志打印在哪
• 异常是怎么处理的

2、看代码时先看主干，再看细节#

推荐顺序：

1. 先看 Controller
2. 再看 Service
3. 再看 Mapper / DAO
4. 最后再看工具类、异常处理、事务、边界逻辑

注意

一开始不要太纠结这些内容：

• 很底层的工具类
• 很复杂的公共封装
• 各种配置细节
• 边缘功能代码

先把主流程搞懂更重要。

3、看代码时重点关注什么？#

优先看这些：

• 主流程
• 参数校验
• 业务校验
• 状态流转
• 异常处理
• 日志打印
• 事务边界

4、善用 IDE#

熟悉项目时，IDE 是你的导航工具。

重点会用这些能力：

• 跳转到定义
• 查找引用
• 查看调用层次
• 全局搜索接口路径、类名、字段名
• 打断点调试

1、一上来就通读全部代码#

这是最容易把自己看崩的方式。 正确做法是：先抓主线，再按需深入。

2、总想一次性全懂#

这基本是不现实的。 项目的理解一定是循序渐进的，不可能刚接触就把所有内容全部吃透。 实际上，很多在公司待了两三年的同事，也未必对整个项目的每一个模块、每一个细节都完全了解。

3、只看代码，不看业务#

会导致你“看得懂代码，不知道为什么这么写”。

4、只看业务，不看技术栈#

这样后面一遇到 Redis、MQ、ES、注册中心、网关，就很容易发虚。

5、只看文档，不动手#

不调接口、不打断点、不看日志，很难真正建立理解。

6、不敢问#

新人最大的问题往往不是不会，而是不好意思问。 实际上，很多项目里的命名、流程、历史包袱，不问根本猜不出来。