快速熟悉一个系统

之所以写这篇文档，是因为自己在做管理的时候，太多的项目根本没办法一个一个去接触，所以需要如何快速熟悉一个系统就成了对我的一个基本要求。
快速熟悉一个系统，首先我认为的最重要的不是对这个系统的细节去扣，而是去梳理他的整个框架图、流程图。通过框架图可以知道这个系统有多少个模块、各个模块之间的大致关系。其次在通过流程图去完善这个框架图。刚开始梳理其中的主流程，对主流程有一个大致的了解了，后续在对配置模板的细节进行完善就快很多了。
如图是我所理解的快速熟悉一个系统的逻辑线：

如何快速熟悉一个系统

一、快速熟悉一个系统

我认为写得很好的一个文章，如何快速熟悉一个系统。参考博文:https://www.cnblogs.com/flashsun/p/9450066.html

现在发现如何快速熟悉一个系统，核心的内容就是逻辑，如何把逻辑理解清楚，是我们首要去处理的问题。

从技术的角度，主要从页面到数据库：一个是整理数据库表，一个是整理Controller层的所有接口。

1.从页面到数据库的线

针对逻辑流程的测试，可能最好的方式是从页面到数据库的线:页面访问路径–前端项目–后台服务–数据库地址。

2.整理数据库表

1. 找核心项目
2. 筛选核心数据表
3. 判断核心表
4. 找出表与表之间的关系

找核心项目： 目标明确，找一个核心项目去展开。

筛选核心数据表： 分2种情况，一个是表少，直接拿工具导出来表结构，一个个看就行了。但如果数据库表特别多，我们首先要将表名全部导出，筛选出那些核心的表。这里导出表名、筛选表以及后面的分析表字段，不妨给自己做个工具。

判断哪些是核心表： 首先排除常规表（备份表、中间表、统计表、日志表、配置表）。比如在公司分析的系统，一共150多个表，其中有好多copy结尾的是备份，flow结尾的是流水，rel结尾的是中间关联表，statistics结尾的是数据统计表，log结尾的是日志表，config结尾的是配置表，等等。其次剩下的表进行分类。比如常规表排除以后也就剩20来张表，再根据它们的名字，可以看出好多表是属于一类的，比如order表就有各种order，按类别再分出来也就四五类，再分析起来就不难了。当然如果是更大的体系结构，那就要再不断做拆解。

找出表之间的关系：在具体分析这些核心表字段之前，还要做一件事就是找出表中间的关系。如果表b中有个字段，比如 叫 a.id，那么b和a就是一对多的关系；如果两个表有rel中间表，那二者就是多对多的关系，起码从逻辑上讲是这样的。这个分析过程可以做个小工具，通过程序来判断。

到此，你就对整体的数据库结构有所了解了。根据表名也能对表的大致内容有所了解，接下来就是针对具体的表，看里面具体的字段和前人给出的备注，这个过程就没有技巧了，要耐心，要慢慢熬。

3.整理controller层的所有接口

当对数据库表做了以上的了解后，你基本上对这个系统能提供什么服务了解得差不多了。这个时候不论你的代码长什么样子，数据库摆在那里，能提供的服务差不多就已经出来了，对有经验的人来讲，代码的业务逻辑也大致能猜到个八九分。

我们梳理了大后方，那接下来就是把最前端和别人交互的部分搞清楚，这样掐头去尾，整个项目就解剖的差不多了。

可以做个小工具，扫描出所有的controller层的接口，展示出方法名、路径名、参数列表和返回值等，但可惜没能展示注释。

和数据库一样，如果接口很少，那么一个个看；如果特别多，还是先找出比较核心的几个方法研究。

可以用postman，把要研究的接口访问保存起来，并且添加访问成功和失败的Example。我推荐自己开发的时候也把postman用起来，越详细越好，postman不只是可以简简单单访问你的接口，还能做批量测试，还可以生成api文档用于和前端交互。这样你不但测试了自己的接口，还省的写文档了。而且postman还有个好处就是可以给自己的接口mock一个服务，这样即使你的接口挂了，或者接口根本就没写好，也可以让前端人员先访问你的mock，完全不影响前端边测试边开发，这才是真正的前后端分离嘛。

4.重新清理项目间的关系

好了，这时候每个项目你已经大致了解，最起码调用的效果，数据库所能提供的服务，你是清楚的。至此，就要重新整理下项目之间的关系了。

根据之前的接口名称，详细了解下项目间的调用关系。理不清的部分去问老员工，这时候你带着自己的了解问，他们也能给出更多的信息。

看看每个项目中用到的中间件，主要是mq服务，看看谁是生产者，谁是消费者，以此来了解关系。

这时你应该已经开了好几轮的周会了，接下来的周会你应该能听懂部分内容。根据每个人的描述和最新的几组需求，逐渐摸清楚现在项目面临的问题，以及哪个项目是核心，哪个项目是辅助，哪个项目是以稳定安全为主的。

到此为止，你对整条业务线就有了大致的了解，接下来就可以结合你具体负责的内容、领导安排你做的方向，去看具体的业务代码了。

虽然之后的步骤依然需要你深入其中，事无巨细地了解具体内容， 但此时，你通过前面的努力，已经可以站在一定的高度看每一个项目了，虽然你细节上还是不了解，但这是完全不同的。

在研究具体业务代码的同时，不断地跳出来看整条业务线的框架，修正之前由于不了解具体业务而理解错误的架构。

长此以往，你一定会在某个项目中脱颖而出，让大家认识到你的全局视野，这也是走出老是写增删改查代码怪圈的一个途径。慢慢会有人意识到，你对项目的理解总能站在全局的视野，很多需要跨项目去做的业务，也会自然而然想到你，慢慢地，你会接触到更为核心的东西，成为架构师，或者去转向产品，转向管理。