最近新接手了一些项目，所以需要从0开始熟悉这些项目，这里正好跟大家分享一下相关的心得。
特殊情况
由于项目是从别的团队跨国交接过来的，而且项目本身处在开发过程中，所以交接的时候会有一些困难。
首先大家都很忙，没有办法正式交接，所以只能先旁敲侧击，尽量的阅读现有代码和文档，多看少问成了一种常态。
其次交接项目其实在一定程度上是抢了别人的饭碗，所以整个过程要非常小心，要照顾对方团队的感受。
如何开始
我是这样开始的。
- 拿到代码库权限，这样可以直接看下代码，了解项目的技术栈，做到心里大致有数
- 拿到文档系统权限，先读一下存量文档
- 拿到监控系统权限，知道项目在监控些什么指标
- 找到对接人，有问题可以稍微问一下
所以看上去这个开始过程跟谈恋爱差不多，先通过各种方式去了解对方，然后再小心翼翼的进行接触。
了解技术栈
接手的系统大概有十几个代码库，分为4-5个项目，其中一个核心项目基本上提供了其他项目所需要的依赖接口。我们暂且将这些系统命名为A/B/C/D。
- 系统A:后端主要使用go实现，用到了go的全栈web框架和grpc；前端主要是react全家桶实现；
- 系统B:后端语言是python，用django实现；前端是nextjs写的；
- 系统C:后端django，前端nextjs；
- 系统D：纯前端项目，用nextjs实现；
nextjs之前没有接触过，所以花了点时间看了看官方文档，因为大致是再react生态中，所以理解起来还是没有太大障碍的
搭建开发环境
我一般通过搭建开发环境来熟悉系统之间的依赖，自己动手做一遍胜过万语千言。
熟悉数据库结构
我一般喜欢从系统的持久化层去熟悉系统的大致逻辑，因为持久化反映了系统处理的结果，代码则反映了系统处理的过程，从结果去反推过程，尽管有点本末倒置，但数据的最终状态相对来说还是比较好去掌握的。
接手的项目里有两个核心系统，A系统有100+表，B系统有60+表，我粗略的将这些表都过了一遍。过的思路是这样的
- 首先在现有文档找实体图，如果有的话可以参考实体间的关系
- 没有实体图就自己找关系，比如外键，这反应了关系表之间的关联关系；一些实体没有外键的，但很明显是一些核心业务实体，比如电商里的订单信息之类的，这时候就需要找关联表，看看是不是有一些表记录了单独的关联关系。这样梳理一遍过后，就可以大致知道数据的结构，了解业务逻辑在数据库层面是如何表达的
- 画出实体之间的关系图，在图中出入线最多的实体大概率就是核心实体，也就是核心表
熟悉数据流向
数据库是数据最终的归宿，但数据在入库前和出库之后都可能会被加工，这些加工的过程就是业务逻辑的体现。那么如何去快速了解数据流向呢？我的经验是通过api。
因为我们的系统是前后端分离的系统，所以业务逻辑的表达大部分都是通过api进行的。通过现有的api文档我们就可以知道系统有哪些功能，这些功能里会用到哪些数据表。把所有的接口都过一遍之后，我大概可以理解系统后端提供了哪些功能。另外交接的小哥给了我一份postman的collection，上面有大部分接口的测试用例，非常管用。
如果没有文档的话只能通过代码去熟悉这个流程了。
画出系统大致的架构图
数据库和数据流向偏向细节，在更宏观的层面上我喜欢画一些简单的部署架构图，注意不是逻辑架构图，来加深我对系统整体的理解。
学会看线上监控
如果有线上监控，那么就要学会看线上监控指标。简单的监控可以分为两个层次
- 基础监控。比如容器的健康度
- 服务监控。比如api的请求数量，耗时以及失败率等
如果没有监控的话，可以考虑将这个基础建设事项放到比较高的优先级去做
学会查日志
日志可以给我们提供很多信息，在这些系统里，之前的开发者都使用了elk做日志存储，因为是相对标准的方案，交接的时候就会比较顺利。
另外由于系统里用到了微服务架构，所以Distributed tracing机制也是必须的，这里就不展开了。
空发布
空发布其实就是给代码加一些注释进行发布，尽管没有产生任何新的功能，不过空发布可以让我们了解系统是如何部署的，以及代码库的管理规范，比如哪个分支用来发布，如何做分支管理等。
输出重构以及迁移思路
看代码的时候总会遇到一些觉得可以重构的地方的，这里可以先记下来，后面再去逐步推动改进。另外项目之前跑在之前开发者维护的k8s上，后面也要想办法把服务迁回来，这个思路可以先有，等完全熟悉了以后再动手去做。
以上就是我对新项目熟悉的过程，不知道大家有什么建议没，欢迎评论哦。