进入一家新公司后,最头疼的就是如何快速了解公司的业务和项目架构。
如果碰到一个特别热心的老员工,事无巨细地给你讲,随时在你身边答疑解惑,那可能还好。但很可惜,我没有碰到这样的人,在加入新公司后,带我的人几乎没有花时间给我讲项目,也没有给我安排一些可以熟悉项目的需求。就这样的一个多月时间里,我慢慢开始靠自己的力量熟悉大概十个项目,并在过程中总结了一些方法,借此机会记录一下,并分享给大家。
注意,这里的策略并非快速了解一个项目的具体业务,这个不同项目也不一样,无法总结。
我的策略是大体了解整个业务线上的所有项目,大概摸清楚每个项目都是干嘛的,他们之间的关系如何,以便以后不论具体负责任何项目不至于找不到方向,具体到细节的业务,虽然需要花时间,但相比对整体上的一头雾水,还是简单许多。
1 业务的本质
并非项目面对的客户是谁啊?、项目用的啥框架啊?而是真的能推出所有现存业务的,仅如下两点:
- 源码位置(如gitlab)
- 部署环境(dev生产/test测试/online线上环境)
项目,其实就是一堆机器上的一堆代码。为节约时间,最好还有wiki、jenkins、页面访问路径、数据库地址,我之所以说那两个必要条件,是想说其实项目本质上就是这么简单的一个事,你千万不要想的太复杂。
业务再复杂,但本质却逃不出这些,你千万不可以糊涂。当你无从下手或者什么都不清楚的时候,那么就主要把源码和环境弄清楚吧,其它的都是附属品。
2 从页面到数据库的线
有了上面的必要条件后,我们就开始了解项目了。由于不只是一个项目,所以千万不要深入具体代码,否则你就越来越烦直到放弃,也不会有好的效果。
对某个具体项目的了解,一定要建立在对整体了解的基础上。这时我们首先为各个项目画出一条线,并标明每一个节点的信息,就像下面的样子:
页面访问路径–前端项目–后台服务–数据库地址
一个前端项目可能对应多个后台服务,所以最终图差不多这样:
这个整理的过程,主要是让自己梳理清楚,有哪些项目,哪些是前端可视,哪些是后台提供服务。
了解到前端项目分别调用哪些后台服务,通过后台服务和数据库名称,能从本质上了解到这条业务线提供了什么功能,从前端项目和页面路径,我们能了解到我们需要给用户展示什么,即注意输入输出。
注意,这个阶段我们只是见名知意,即使点开页面,连接上数据库看看,也千万别花过多的时间,这个阶段的重点就是仅仅知道,这条业务线提的整体内容。
在此基础上,这个图可以不断细化,比如项目部署的机器,可以标注在项目旁,或保存在xshell。
此外所有非业务相关的,能查到的尽量都记录下来,这个真的为以后找各种东西方便太多了,否则别看你现在节约了时间,把以后查找相关东西的时间加起来,将会是天文数字了。
由于这部分的信息没人会一个一个地告诉你,就算有也不可能说的特别全。所以我是借助jenkins来整理的。项目部署都需要用到jenkins,只要查看jenkins配置的命令,就可以把部署环境一一整理出来,这个我认为是最全而且最新的。不要和我说查wiki,如果公司wiki都写的这么全,我估计就没这篇文章什么事了。当时我的jenkins权限特别少,只能看一部分项目,而且还只能执行,不能看配置,带我的人也是抠门,每次问他都给我开通所需要的项目的执行权限,多一点都不给。后来我也懒得问了,由于jenkins机器大家都可以用root权限登陆,所以我进入jenkins的配置文件config.xml,给我自己添加了一个admin权限,重启jenkins,再打开之后屏幕满满的项目都出来了,而且都可以查看和修改,畅通无阻。我就这样通过一个个jenkins的配置,整理了部署的机器,也看了下启动的逻辑。
3 了解项目间的关系
这部分如果有老员工愿意和你说说,那最好还是了解一下。如果没有也没关系,先跳过这段,以后慢慢了解也是可以的。
4 整理数据库表
上面都是整理项目的大体框架,还没有涉及到具体的项目细节。这一部分,仍然不去涉及。如果说站在整个业务的本质上看,业务无非就是一堆代码运行在一堆机器上。那么站在单个项目来看,一个项目无非就是对数据库的增删改查操作而已,或者从使用者的角度看,一个项目就是输入一些参数得到一些返回结果。所以接下来我们要做两件事,一个是整理数据库表,一个是整理Controller层的所有接口。
这里首先要选择一个核心项目去看,众多项目中一定有一个是核心项目,先从这个开始看起。
如果数据库的表比较少,那我们拿工具导出来表结构,一个个看就行了,这个不难。但如果数据库表特别多,我们首先要将表名全部导出,筛选出那些核心的表。这里导出表名、筛选表以及后面的分析表字段,不妨给自己做个工具,我在遇到一些很麻烦的或者感觉以后还可以通用的事情时,就会做成一个小工具,放在一个我给自己起名为javamate的程序中,这些小工具逐渐积累起来你会发现今后有意想不到的方便。
话说回来,如何判断哪些是核心表呢,不要着急,我们首先排除掉一些没用的。拿我在公司分析的系统来说,一共150多个表,其中有好多copy结尾的是备份,flow结尾的是流水,rel结尾的是中间关联表,statistics结尾的是数据统计表,log结尾的是日志表,config结尾的是配置表。等等。排除掉这些对核心业务理解无影响的表之后,所剩的也就20来张表,再根据他们的名字,可以看出好多表是属于一类的,比如order表就有各种order,按类别再分出来也就四五类,再分析起来就不难了。当然如果是更大的体系结构,那就要再不断做拆解。
再具体分析这些核心表字段之前,还要做一件事就是找出表中间的关系。如果表b中有个字段叫比如a.id,那么b和a就是一对多的关系,如果两个表有rel中间表,那二者就是多对多的关系,起码从逻辑上讲是这样的。这个分析过程我也是做了个小工具,通过程序来判断的。
到此,你就对整体的数据库结构有所了解了。根据表名也能对表的大致内容有所了解,接下来就是针对具体的表,看里面具体的字段和前人给出的备注,这个过程就没有技巧了,要耐心,要慢慢熬。