p/how-to-take-over-a-project/

[giscus[bot]]

p/how-to-take-over-a-project/

在工作中，接手负责管理别人开发或者前人开发的项目是每个开发人员的工作任务之一，那么，如何快速并且高效的消化接手过来的项目呢，本文主要讲解一些方法与实践技巧，希望可以帮助你快速了解你接手的项目。
系统文档 若是有最开始的包括后续优化的相关技术文档或者系统文档，对于接手过来的项目无疑是最有助于开发人员的方式。但是大家会发现往往接手过来的项目是没有这一类的文档的，交接过来的系统若是对开发有极高追求的，一般都会有文档，并且 README.md 中会有项目介绍包括相关文档，但是…… 往往我们拿到手的系统是纯代码，README.md 可能都没有这个文件，这种往往是最痛苦的，不过也是最锻炼梳理系统这项技能的。
那么我们就需要从下面这几个点来慢慢消化系统。
系统权限 交接过来的系统，一定要开好对应的权限，这对你全面了解系统以及后续维护系统有着至关重要的的作用，若没有权限，当系统出现问题时，领导找到你问问题原因，而你却在向领导申请权限，世纪名场面。
以下是常见的系统权限：
Gitlab 仓库权限； Deploy 部署系统权限； Log 日志系统权限； Data 数据库管理系统权限； Alert 系统报警配置权限； Crond 任务调度器权限； Middleware 根据不同系统的中间件权限，包括不限于 Notify、RocketMQ、Redis 等； Auth 依赖系统授权信息权限； Test 测试平台的权限； API API 调试平台的权限； Sys 系统相关注册管理权限； 接手项目，开启权限是第一步也是必须要做的事情。
配置文件 通过配置文件可以看到一个系统的基本信息，比如说：
系统环境配置信息、注册信息、协议相关信息； 系统使用数据库配置信息； 系统使用 Redis 等中间件配置信息； 业务上使用的一些值定义； 库表设计 一般数据库表设计会存放在 dao 模块或者目录下，基本上是一表一文件定义，可以看到表定义的字段，并且可以看到对该表的一些“增删查改”动作。
若是底层系统设计，本身系统就是只提供给外部服务使用的，那么从数据库库表设计基本上就可以反推业务逻辑的设计，删除、更新、新增都是基本的业务逻辑动作，查询或者组合成事务的业务相对来说比较复杂，不过根据业务代码看着理解的话也比较简单一些。
缓存设计 缓存一般有两种，分别是：
被动缓存：一般是用于高并发场景，用于缓解下游中间件或者接口的瞬时压力； 主动缓存：这种是相对高级的缓存策略，用于分布式数据一致数据的返回； 分析刚接手的系统，从 cacheKey 就可以了解业务系统中为什么这样设计的：
1 product.info.pid.XXXX 上面这个例子可以看到记录的是一个产品 pid 为 XXXX 的缓存信息。
协议文件 若是接手过来的系统按照语义命名及划分路由的话，则通过 API 接口文档来看是一个很好的方式，因为通过 API 基本可以确定接手过来的服务有哪些业务，针对不同的业务又有哪些操作。

https://blog.debuginn.cn/p/how-to-take-over-a-project/