接手项目要做的事项
总结：在接手别人的项目时，至少应该自己整理并绘画四个图
1、产品脑图：帮助你理解产品的功能；
2、UML时序图：帮助你源代码的核心技术实现；
3、整体业务泳道图：帮助你从整体上熟悉业务的流程；
4、系统架构图：帮助你掌握目前服务器的部署情况和网络链路。
熟悉产品、熟悉业务、熟悉技术
接手一个旧项目，第一要义：尽快熟悉你的产品。这个产品具体主要功能是什么？是给谁使用的？客户群体是谁？目前大概注册和使用的用户有多少？上游供应商是谁？项目组的其他成员还有哪些？等等这些项目和产品背景信息都要搞清楚。
第二要义：尽快熟悉业务。业务很关键，你要对接手的产品所在的行业有一定的理解和学习。也就是我们通常所说的特定领域的业务。这个业务到底是做电商、还是做广告、还是做游戏、还是做ToB的系统集成，不同领域的术语和知识也不同。
第三要义：快速了解当前项目所用到的技术栈、编程语言、开发框架、数据库、环境要求等。技术是基础。
开始开发一些小需求和小功能
当你要开始开发新的需求时，先不要着急去改代码。
因为，你会发现，写代码很简单，但要写出100%符合原来业务逻辑和规则的代码就很难。
也就是说，编程语言的代码语法不难，难就难在完整理解和全盘掌握原来代码的业务逻辑。
为此，你可以使用ProcessOn、Xmind、Viso等在线工具或本地软件，先自我梳理一遍目前产品和技术上的思维脑图、核心业务逻辑的时序图、整体业务流程的泳道图、目前系统的架构图。至少可以梳理这四个图。
例如，产品功能的思维脑图梳理，帮助你了解产品的功能和形态。通过点击、浏览、体验和使用产品的每一个页面，你可以边操作边梳理。
然后，打开本地IDE代码编辑器，找到对应页面和接口背后的源代码，定位到最底层、最核心、最重要、最复杂的代码模块，边浏览源代码、边整理核心的时序图。这一块工作，可以让你抓住项目的底层本质和核心，熟悉原来的代码风格、编程范式、设计模式、高并发的处理方式、各模块的依赖关系等。
第三个图，是整体业务的泳道图。它可以让你知道整体的系统上下游的数据流向、底层的依赖系统和网络链路。当你的系统出现问题了，你知道可以找谁。
最后一部分是面向技术架构的系统架构图。这部分，你可以通过nginx日记、或者阿里开通的服务、以及内部记录的资料找出你的系统都调用了哪些第三方接口。例如短信接口用的是哪家？有没用到OSS对象存储？CDN用了什么？数据库是用云服务还是自建的？你要清楚地知道目前有多少台服务器，是如何部署和相互调用的，网络链路是怎样的。从用户发起请求打开页面开始，系统在背后都做了哪些事情？
接手实战经验：
- 开通各种资源权限：云账号、git、流水线、机器部署、监控、告警、日志、配置文件管理、网关、负载均衡、数据库、redis、ES、产品体验账号
- 体验产品功能、梳理功能脑图、产品服务的客户、用户和数据量级、qps等
- 整理服务调用的第三方接口、第三方依赖、消息监听、消息发送、存储方式（数据库、缓存、ES、COS……）、CDN、服务部署方式
- 梳理服务的定时任务、服务启动时初始化内容、拦截器过滤器的内容
- 本地启动服务、配置文件管理方式、发布上线流程
- 准备日常查问题处理问题的工具：常用数据库查询语句SQL等
业务(项目是业务的一环) —> 产品(项目) —> 代码(技术栈)
切记勿一开始就一行一行代码的抠，需要开发或者修改代码的时候再细看，否则既容易把自己绕晕又低效，需要快速全局把控，然后快速做需求，根据情况平时再细细梳理到完全掌控。
参考：CTO来教你：技术人员突然离职，如何接手他的项目？-腾讯云开发者社区-腾讯云