共计 3574 个字符，预计需要花费 9 分钟才能阅读完成。
首发于：https://blog.debuginn.cn
在工作中，接手负责管理他人开发或者前人开发的我的项目是每个开发人员的工作工作之一，那么，如何疾速并且高效的消化接手过去的我的项目呢，本文次要解说一些办法与实际技巧，心愿能够帮忙你疾速理解你接手的我的项目。
零碎文档
若是有最开始的包含后续优化的相干技术文档或者零碎文档，对于接手过去的我的项目无疑是最有助于开发人员的形式。然而大家会发现往往接手过去的我的项目是没有这一类的文档的，交接过去的零碎若是对开发有极高谋求的，个别都会有文档，并且 README.md 中会有我的项目介绍包含相干文档，然而 …… 往往咱们拿到手的零碎是纯代码，README.md 可能都没有这个文件，这种往往是最苦楚的，不过也是最锤炼梳理零碎这项技能的。
那么咱们就须要从上面这几个点来缓缓消化系统。
零碎权限
交接过去的零碎，肯定要开好对应的权限，这对你全面理解零碎以及后续保护零碎有着至关重要的的作用，若没有权限，当零碎呈现问题时，领导找到你问问题起因，而你却在向领导申请权限，世纪名局面。
以下是常见的零碎权限：
- Gitlab 仓库权限；
- Deploy 部署零碎权限；
- Log 日志零碎权限；
- Data 数据库管理系统权限；
- Alert 零碎报警配置权限；
- Crond 任务调度器权限；
- Middleware 依据不同零碎的中间件权限，包含不限于 Notify、RocketMQ、Redis 等；
- Auth 依赖零碎受权信息权限；
- Test 测试平台的权限；
- API API 调试平台的权限；
- Sys 零碎相干注册管理权限；
接手我的项目，开启权限是第一步也是必须要做的事件。
配置文件
通过配置文件能够看到一个零碎的根本信息，比如说：
- 零碎环境配置信息、注册信息、协定相干信息；
- 零碎应用数据库配置信息；
- 零碎应用 Redis 等中间件配置信息；
- 业务上应用的一些值定义；
库表设计
个别数据库表设计会寄存在 dao 模块或者目录下，基本上是一表一文件定义，能够看到表定义的字段，并且能够看到对该表的一些“增删查改”动作。
若是底层零碎设计，自身零碎就是只提供给内部服务应用的，那么从数据库库表设计基本上就能够反推业务逻辑的设计，删除、更新、新增都是根本的业务逻辑动作，查问或者组合成事务的业务相对来说比较复杂，不过依据业务代码看着了解的话也比较简单一些。
缓存设计
缓存个别有两种，别离是：
- 被动缓存 ：个别是用于高并发场景，用于缓解上游中间件或者接口的刹时压力；
- 被动缓存 ：这种是绝对高级的缓存策略，用于分布式数据统一数据的返回；
剖析刚接手的零碎，从 cacheKey 就能够理解业务零碎中为什么这样设计的：
product.info.pid.XXXX下面这个例子能够看到记录的是一个产品 pid 为 XXXX 的缓存信息。
协定文件
若是接手过去的零碎依照语义命名及划分路由的话，则通过 API 接口文档来看是一个很好的形式，因为通过 API 根本能够确定接手过去的服务有哪些业务，针对不同的业务又有哪些操作。
针对不同的语言、不同的协定，也有一些轻微的差异：
Java Dubbo 协定
个别 Java Dubbo 协定都是对外提供 API 模块的 pom 依赖的，申明都是应用接口来实现的：
// XXXX 业务模块
public interface XXXX {
// 获取列表
Result<DataA> getXXXList(Context ctx, XXRequest req);
// 获取列表 基于 uid
Result<DataA> getXXXListByUid(Context ctx, XXRequest req);
// 基于 uid 删除 XX 信息
Result<Boolean> delXXInfoByUid(Context ctx, XXRequest req);
}Go Thrift 协定
Go Thrift 是应用 IDL 语言定义的协定，咱们会基于 IDL 申明的接口，定义好接口出入参生成的 SDK 文件，通过看 IDL 定义的接口，就能够理解到接手的我的项目提供了哪些性能了：
struct XXOrderResponse {
1:i64 orderId,
2:string orderInfo;
}
struct XXOrderRequest {1:i64 orderId (go.tag = "json:\"order_id\""),
}
// 接口定义
service OrderService {
// XX 订单
XXOrderResponse XXOrderInfo(1:XXOrderRequest params)
}Go HTTP 协定
目前公司应用居多的 HTTP 框架是 iris 还有一个自研的 migo 框架（基于 beego 框架开发），都有一个类似的特点，就是会把 router 独自定一个文件，即 router.go :
// Init _
func Init(app *iris.Application) {app.Use(middlewares.RecoveryMiddle)
app.Use(middlewares.PromeMiddle)
app.Use(middlewares.LoggerMiddle()) // 小心打日志的配置
app.Use(innermiddle.CrossOrigin) // 是否应用跨域
app.Use(middlewares.RateLimitMiddleWare) // 配置限流
app.PartyFunc("/product", cproduct.Register)
return
}编程语言
从依赖方去开掘零碎，看零碎依赖了哪些业务方，也能够看出零碎依赖了哪些根底包，还能够看到依赖的包对应版本（有教训的人能够看出是否有 bug）。
Java Maven
目前 Java 支流的依赖形式就是应用 Maven POM 定义依赖并治理依赖：
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<artifactId>product</artifactId>
<groupId>cn.debuginn.blog</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>product-server</artifactId>
<dependencies>
<dependency>
<groupId>cn.debuginn.blog</groupId>
<artifactId>product-api</artifactId>
<version>${product-api-version}</version>
</dependency>
<!-- 单元测试 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
</dependency>
</dependencies>
</project>Go Module
目前 Go 语言也是大一统到 go mod 治理版本依赖了，因为 Go 是源码依赖，应用 go mod tidy 之后就能够通过点击依赖仓库来看源码了：
module github.com/debuginn/go-demo
go 1.20
require (
github.com/dubbogo/gost v1.11.25 // indirect
github.com/go-playground/validator/v10 v10.10.1
github.com/go-redis/redis/v8 v8.11.0
github.com/gobwas/ws v1.0.3 // indirect
)流程图、泳道图
通过上述形式与办法，最初就能够依据业务代码，画出业务流程图及对应的泳道了，同时，也能够基于依赖关系，画出零碎的架构图，梳理一个零碎的最好形式就是有所积淀，通过读代码把代码转化为文档的形式即能够对消化的零碎有所输入，又能够晋升本人的技术能力。
写在最初
最初， 一个好的零碎，是由零碎设计文档、代码、正文和覆盖率尽可能全面的测试用例组成的 ，很多状况下大家因为不可抗拒的起因，最初只留下了运行的代码，这也是撰写本文的次要起因，心愿对大家有所帮忙，最初大家有什么好的形式和办法也能够在评论区分享进去，让咱们一起变得更强。
