专栏首页chenchenchen新人如何快速熟悉一个新项目

新人如何快速熟悉一个新项目

本文来自:https://www.cnblogs.com/flashsun/p/9450066.html

很多新人进入一家新公司后,最头疼的就是如何快速了解公司的业务和项目架构。

因为文档很少,没有文档,或者是文档严重落伍, 根本没法看;如果你碰到一个特别热心的老员工,事无巨细地给你讲,随时在你身边答疑解惑, 那简直是天大的好运气, 现实是大家都很忙,没人给你讲解。

很快就要深入项目做开发了,怎么办呢?

一. 必要条件

这里说的必要条件不是“项目面对的客户是谁”,“项目用的框架是什么”这种,而是真真正正的必要条件,就好比用几条数学公理能推出整个数学体系一样。这里我总结的真正的必要条件只有这两点:

源码位置(gitlab或svn)

部署环境(dev/test/online)

所谓项目,其实就是一堆代码放在了一堆机器上而已,所以这些就足够了。当然,为了更加节约时间,也要获得wiki、jenkins、页面访问路径、数据库地址等相关信息。

我之所以说那两个必要条件,是想说其实项目本质上就是这么简单的一个事,你千万不要想的太复杂。

它的业务可以无限复杂,但它的本质却逃不出这些,你千万不可以糊涂。当你无从下手或者什么都不清楚的时候,那么就主要把源码和环境弄清楚吧,其它的都是附属品。

二. 从页面到数据库

有了上面的必要条件后,我们就开始了解项目了。由于不只是一个项目,所以千万不能深入具体代码,否则你就越来越烦,怀疑人生,很快放弃。

对某个具体项目的了解,一定要建立在对整体了解的基础上。这时我们首先为各个项目画出一条线,并标明每一个节点的信息,就像下面的样子:

页面访问路径--前端项目--后台服务--数据库地址

这里的一个前端项目可能对应多个后台服务,所以最终的图应该差不多是这样:

这个整理的过程,主要是让自己梳理清楚,一共有哪些项目,哪些是前端可视的,哪些是后台提供服务的。

了解前端项目分别调用了哪些后台服务,通过后台服务和数据库的名称,我们能从本质上了解到这条业务线提供了什么功能,从前端项目和页面路径,我们能了解到我们需要给用户展示什么。

注意,这个阶段我们只是见名知意,即使点开页面,连接上数据库看看,也千万别花过多的时间,这个阶段的重点就是仅仅知道,这条业务线提的整体内容。

在此基础之上,这个图可以不断细化,比如项目部署的机器,我们可以标注在项目旁边,或者保存在xshell里。此外所有非业务相关的,能查到的尽量都记录下来,这个真的为以后找各种东西方便太多了,否则别看你现在节约了时间,把以后查找相关东西的时间加起来,将会是天文数字了。

这里关于整理项目部署的机器还有个小插曲,跟大家分享一下。由于这部分的信息没人会一个一个地告诉你,就算有也不可能说的特别全。所以我是借助jenkins来整理的。项目部署都需要用到jenkins,只要查看jenkins配置的命令,就可以把部署环境一一整理出来,这个我认为是最全而且最新的。

不要和我说查wiki,如果公司wiki都写的这么全,我估计就没这篇文章什么事了。当时我的jenkins权限特别少,只能看一部分项目,后来费了很大的劲,想了很多办法才看到项目的配置,整理出了部署的机器。

三. 了解项目间的关系

这部分如果有老员工愿意和你说说,那最好还是了解一下。如果没有也没关系,先跳过这段,以后慢慢了解也是可以的。

四. 整理数据库表

我们上面都是整理项目的大体框架,还没有涉及到具体的项目细节。这一部分,仍然不去涉及。

如果说站在整个业务的本质上看,业务无非就是一堆代码运行在一堆机器上。那么站在单个项目来看,一个项目无非就是对数据库的增删改查操作而已,或者从使用者的角度看,一个项目就是输入一些参数得到一些返回结果。

所以接下来我们要做两件事,一个是整理数据库表,一个是整理Controller层的所有接口

这里首先要选择一个核心项目去看,众多项目中一定有一个是核心项目,先从这个开始看起。

如果数据库的表比较少,那我们拿工具导出来表结构,一个个看就行了,这个不难。但如果数据库表特别多,我们首先要将表名全部导出,筛选出那些核心的表。

这里导出表名、筛选表以及后面的分析表字段,不妨给自己做个工具,我在遇到一些很麻烦的或者感觉以后还可以通用的事情时,就会做成一个小工具,放在一个我给自己起名为javamate的程序中,这些小工具逐渐积累起来你会发现今后有意想不到的方便。

话说回来,如何判断哪些是核心表呢,不要着急,我们首先排除掉一些没用的。拿我在公司分析的系统来说,一共150多个表,其中有好多copy结尾的是备份,flow结尾的是流水,rel结尾的是中间关联表,statistics结尾的是数据统计表,log结尾的是日志表,config结尾的是配置表。等等。

排除掉这些对核心业务理解无影响的表之后,所剩的也就20来张表,再根据他们的名字,可以看出好多表是属于一类的,比如order表就有各种order,按类别再分出来也就四五类,再分析起来就不难了。当然如果是更大的体系结构,那就要再不断做拆解。

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

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

五. 深入代码层

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

我认为一个业务相关的项目代码只分三个部分:

1. 通过交互对自身数据库进行增删改查操作

2. 通过定时任务或服务器脚本对自身数据库进行增删改查操作

3. 调用或通知其他服务做一些事情

如果只是单一项目,无非就是通过各种途径去玩自己的数据库而已,前两点足够了。而如果是微服务部署,那么加一个第三点足矣。我们将代码逻辑分成这三个部分看,快速了解一个项目就不成问题,甚至在你没有看过某一项目而突然有一个bug要你解决时,你也可以按照这种方式去快速定问问题。

通过交互对自身数据库进行增删改查操作

这个无非是最简单的一部分,即使复杂也是代码较长,表较多而已。所谓的交互,或许是Controller暴露给前端用户的接口,或许是开一个rpc端口暴露给其他微服务的接口,总之是第三方去触发的。

这里我也给自己做了个小工具,扫描出所有的暴露服务的接口,展示出方法名,路径名,参数列表和返回值等。

和数据库一样,如果接口很少那么一个个看,如果特别多,还是先找出比较核心的几个方法研究。这里我用的是postman,把要研究的接口访问保存起来,并且添加访问成功和失败的Example。

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

整理出所有接口后,肯定大部分是很简单的,一看就懂,一层一层点进去直到数据库层的sql语句,该接口最本质的东西就出来了。

如果是复杂的,那就一步一步debug,花时间总是可以分析的。如果再复杂的,你可以画流程图(这里我比较推荐用processon)。甚至几个接口围绕一个功能的,你可以画状态流转图。比如我之前看我们公司处理订单业务这块,逻辑确实比较复杂,我就画了类似如下的图:

状态流转图:横轴代表order_status字段的状态,纵轴代表当order_status是以上状态时,触发该接口操作会使该字段发生什么变化)

接口对表的影响图:这里你可以把所有涉及到的表以及表中的关键字段列举出来,然后看分别调用接口后对各个表字段的影响,变化的就用红色标出

有了这两种维度的视角,我相信再复杂的业务都能很理清楚,也能发现某些bug最本质的问题。

我正是通过这样的方式,把一个本来不属于我的项目短时间内了解清楚,快速准确地修复了好多顽固的bug

虽然项目很烂,业务逻辑十分混乱,但正是这样一段时间锻炼了我深入代码理清逻辑的能力,也有了自己独特的一套方法。

定时任务或服务器脚本

这个和第一种类型一样,只不过换了个入口。比如定时任务,或者启动的时候就开启的一些线程。

寻找这些入口的确不是特别容易,比较头疼,但也只是入口比较隐蔽而已。找到他,记下来,具体分析过程还是按照上述方法去分析,就可以了。

调用或通知其他服务做一些事情

代码中可能有通过mq给其他服务发消息,或者直接调用其他服务的接口,或者调用类似云推送的接口让它去帮忙像mq发消息。

这部分代码可能更加隐蔽,但数量少,逻辑也简单,你需要做的仍然只是找到它们。这部分也是为了解项目之间的关系打下伏笔。

这三种类型的代码研究清楚后,对于一个业务型的项目来说,已经基本足够了。

对于一些基础服务和中间件类型的服务,还是得慢慢积累技术深度才行。由于本篇文章是快速了解一个业务型的项目,所以就不展开叙述了。

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

好了,这时候每个项目你已经大致了解,最起码调用的效果,数据库所能提供的服务,甚至某些关键部分的本质逻辑,你是清楚的。这个时候,要重新整理下项目之间的关系。

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

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

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

到此为止,整条业务线你就有了大致的了解,接下来就要结合你具体负责的内容,领导安排你做的方向,去看具体的业务代码了。深入其中,事无巨细地了解。

但此时,你通过前面的努力,你已经可以站在一定的高度看每一个项目了,虽然你细节上还是不了解,但这是完全不同的。

在研究具体业务代码的同时,不断地跳出来看整条业务线的框架,修正之前由于不了解具体业务而理解错误的架构。长此以往,你一定会在某个项目中脱颖而出,让大家认识到你的全局视野,这也是走出老是写增删改查代码怪圈的一个途径。

慢慢会有人意识到,你对项目的理解总能站在全局的视野,很多需要跨项目去做的业务,也会自然而然想到你,慢慢地,你会接触到更为核心的东西,成为架构师,或者去转向产品,转向管理。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 基于Python的SQLite基础知识学习

    前一段时间偶然的看到了一个名词SQLite3,大概了解到此为一种轻量型的关系型数据库。官网介绍到SQLite是一个进程内库,它实现了一个自包含的、无服务器的、零...

    JiekeXu之路
  • 腾讯云数据库亮相数据库顶级会议SIGMOD

    | 导语ACM SIGMOD/PODS 2019 数据管理国际会议于6月30日到7月5日在荷兰首都阿姆斯特丹召开。腾讯技术团队直击现场第一时间带回大会盛况。

    腾讯云数据库 TencentDB
  • input disabled不能提交表单

    今天,在开发过程中发现一个问题,在提交form表单时,有一个input一直不能被提交,后台一直报错!究其原因,是因为该input上设置了disabled属性。...

    奋飛
  • ORM 实例教程

    本文来自阮一峰老师的《ORM 实例教程》,如果你用来laravel类的框架,应该对orm有一定的熟悉了,本文是做个深入的理解学习。

    苏生不惑
  • 什么是spring

    从这一篇开始,我们将学习spring框架的知识,spring无疑是现在Java开发框架最火爆的开源框架之一。正是因为spring是开源的框架,所以我们可以很容易...

    吉林乌拉
  • 被神话的大数据——从大数据(big data)到深度数据(deep data)思维转变

    自从阿法狗战胜人类顶级棋手之后,深度学习、人工智能变得再一次火热起来。有些人认为,深度学习的再一次兴起是源于硬件的提升、数据量的增多以及高效...

    用户3578099
  • Git Pro深入浅出(一)

    什么是“版本控制”?版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。 版本控制系统(VCS)应用而生。有了它你就可以将某个文...

    奋飛
  • Oracle OCP考试经验总结与心得体会

    本人于2018年10月27日星期六考完Oracle OCP 1Z0-053,周末休息一天,今天简单的说一说我的考试心得吧。

    JiekeXu之路
  • Mysql事物隔离

    最近工作内容需要向一张表里面写入数据,有两个实现方法,每种方法会运行得到一份结果,两个结果的key会有大部分重复,后面跟的value会有不同。 表格中只允许两个...

    用户3578099
  • MySQL5.6安装&修改root密码&创建一定权限用户

    1. 压缩版MySQL,解压完后在:我的电脑->属性->高级->环境变量 选择PATH,在其后面添加mysql bin文件夹的路径 (如:C:\Program...

    奋飛

扫码关注云+社区

领取腾讯云代金券