精华内容
下载资源
问答
  • 程序员怎样快速熟悉业务和项目

    千次阅读 2018-11-20 17:03:46
    程序员怎样快速熟悉业务和项目?  边开发需求边熟悉项目:先从简单的需求开始。  开发的功能所涉及到的接口,了解一下,当然不要扣细节,先要整体上了解业务;  业务开发时候,细节就很重要了。  这个接口...

    程序员怎样快速熟悉业务和项目?

    1.     边开发需求边熟悉项目:先从简单的需求开始。
    2.     开发的功能所涉及到的接口,了解一下,当然不要扣细节,先要整体上了解业务;
    3.     业务开发时候,细节就很重要了。
    4.     这个接口涉及到的数据库表,种类,字段,和其他表的关联关系。
    5.     这个时候就会对这个业务有一个大概的了解了。
    6.     这样的不通种类的接口看了一些后,业务也就了解的差不多了。
    展开全文
  • 加入新公司,怎样快速熟悉业务和项目?

    千次阅读 多人点赞 2018-09-10 14:14:00
    很多新人进入一家新公司后,最头疼的就是如何快速了解公司的业务和项目架构,或者说不要求快速,即便有足够的时间,也很难在庞大的业务中整理出思绪。当然,如果你碰到一个特别热心的老员工,事无巨细地给你讲,随时...

    很多新人进入一家新公司后,最头疼的就是如何快速了解公司的业务和项目架构,或者说不要求快速,即便有足够的时间,也很难在庞大的业务中整理出思绪。当然,如果你碰到一个特别热心的老员工,事无巨细地给你讲,随时在你身边答疑解惑,那可能还好。

    但很可惜,我没有碰到这样的人,在加入新公司后,带我的人几乎没花时间给我讲项目,也没给我安排可以熟悉项目的任务。

    就这样的一个多月时间里,我慢慢靠自己的力量熟悉了大概十个项目,并在过程中总结了一些方法,借此机会记录一下,分享给大家。

    首先在这里强调一点,我的策略 不是快速了解一个项目的具体业务,因为这个不同项目也不一样,无法总结。我的策略是大体了解整个业务线上的所有项目,大概摸清楚每个项目都是干嘛的,它们之间的关系如何,以便以后不论具体负责哪个项目都不至于找不到方向。

    这样等到需要负责具体到细节的业务时,虽然依然需要花时间,但相比整体一头雾水地开始,还是简单许多的。

    一、必要条件

    我们首先要想的是,有了哪些必要条件后,给你足够的时间,你才能够完全了解整个项目?

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

    源码位置(gitlab或svn);

    部署环境(dev/test/online);

    所谓项目,其实就是一堆代码放在了一堆机器上而已,所以这些就足够了。

    当然,为了更加节约时间,最好还要有wiki、jenkins、页面访问路径、数据库地址。

    我之所以说那两个是必要条件,是想说其实项目本质上就是这么简单的一个事,你千万不要想的太复杂。 它的业务可以无限复杂,但它的本质却逃不出这些,你千万不可以糊涂。当你无从下手或者什么都不清楚的时候,就主要把源码和环境弄清楚吧,其它的都是附属品。

    二、从页面到数据库的线

    有了上面的必要条件后,我们就开始了解项目了。由于不只是一个项目,所以千万不能深入具体代码,否则你就越来越烦直到放弃,也不会有好的效果。

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

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

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

    13465705-489216bb2e79a8b5.jpg!web

    这个整理的过程,主要是让自己梳理清楚,一共有哪些项目,哪些是前端可视的,哪些是后台提供服务的,并且大致了解前端项目分别调用了哪些后台服务。通过后台服务和数据库的名称,我们能从本质上了解到这条业务线提供了什么功能;从前端项目和页面路径,我们能了解到我们需要给用户展示什么。

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

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

    这里关于整理项目部署的机器还有个小插曲,跟大家分享一下。

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

    不要和我说查wiki,如果公司wiki都写的这么全,我估计就没这篇文章什么事了。当时我的jenkins权限特别少,只能看一部分项目,而且还只能执行,不能看配置,带我的人也是抠门,每次问他都给我开通所需要的项目的执行权限,多一点都不给。后来我也懒得问了,由于jenkins机器大家都可以用root权限登陆,所以我进入jenkins的配置文件config.xml,给我自己添加了一个admin权限,重启jenkins,再打开之后屏幕满满的项目都出来了,而且都可以查看和修改,畅通无阻。我就这样通过一个个jenkins的配置,整理了部署的机器,也看了下启动的逻辑。

    三、了解项目间的关系

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

    四、整理数据库表

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

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

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

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

    筛选核心数据表: 如果数据库的表比较少,那我们拿工具导出来表结构,一个个看就行了,这个不难。但如果数据库表特别多,我们首先要将表名全部导出,筛选出那些核心的表。这里导出表名、筛选表以及后面的分析表字段,不妨给自己做个工具,我在遇到一些很麻烦的或者感觉以后还可以通用的事情时,就会做成一个小工具,放在一个我给自己起名为javamate的程序中,这些小工具逐渐积累起来你会发现今后有意想不到的方便。

    判断哪些是核心表: 不要着急,我们首先排除掉一些没用的。拿我在公司分析的系统来说,一共150多个表,其中有好多copy结尾的是备份,flow结尾的是流水,rel结尾的是中间关联表,statistics结尾的是数据统计表,log结尾的是日志表,config结尾的是配置表,等等。排除掉这些对核心业务理解无影响的表之后,所剩的也就20来张表,再根据它们的名字,可以看出好多表是属于一类的,比如order表就有各种order,按类别再分出来也就四五类,再分析起来就不难了。当然如果是更大的体系结构,那就要再不断做拆解。

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

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

    五、整理Controller层接口

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

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

    这里我也给自己做了个小工具,扫描出所有的controller层的接口,展示出方法名、路径名、参数列表和返回值等,但可惜没能展示注释,有大神有想法的话也欢迎帮我想想。

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

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

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

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

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

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

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

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

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

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

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

    这就是我总结的了解项目的过程,我工作年限不多,经验上还不够丰富,希望大佬们多多留言指点,提出问题,共同进步。

    欢迎Java工程师朋友们加入Java进阶高级架构群:855355016

    本群提供免费的学习指导 架构资料 以及免费的解答

    不懂得问题都可以在本群提出来 之后还会有职业生涯规划以及面试指导

    展开全文
  • 很多新人进入一家新公司后,最头疼的就是如何快速了解公司的业务和项目架构,或者说不要求快速,即便有足够的时间,也很难在庞大的业务中整理出思绪。当然,如果你碰到一个特别热心的老员工,事无巨细地给你讲,随时...

    很多新人进入一家新公司后,最头疼的就是如何快速了解公司的业务和项目架构,或者说不要求快速,即便有足够的时间,也很难在庞大的业务中整理出思绪。当然,如果你碰到一个特别热心的老员工,事无巨细地给你讲,随时在你身边答疑解惑,那可能还好。

    但很可惜,我没有碰到这样的人,在加入新公司后,带我的人几乎没花时间给我讲项目,也没给我安排可以熟悉项目的任务。

    就这样的一个多月时间里,我慢慢靠自己的力量熟悉了大概十个项目,并在过程中总结了一些方法,借此机会记录一下,分享给大家。

    首先在这里强调一点,我的策略 不是快速了解一个项目的具体业务,因为这个不同项目也不一样,无法总结。我的策略是大体了解整个业务线上的所有项目,大概摸清楚每个项目都是干嘛的,它们之间的关系如何,以便以后不论具体负责哪个项目都不至于找不到方向。

    这样等到需要负责具体到细节的业务时,虽然依然需要花时间,但相比整体一头雾水地开始,还是简单许多的。

    一、必要条件

    我们首先要想的是,有了哪些必要条件后,给你足够的时间,你才能够完全了解整个项目?

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

    源码位置(gitlab或svn);

    部署环境(dev/test/online);

    所谓项目,其实就是一堆代码放在了一堆机器上而已,所以这些就足够了。

    当然,为了更加节约时间,最好还要有wiki、jenkins、页面访问路径、数据库地址。

    我之所以说那两个是必要条件,是想说其实项目本质上就是这么简单的一个事,你千万不要想的太复杂。 它的业务可以无限复杂,但它的本质却逃不出这些,你千万不可以糊涂。当你无从下手或者什么都不清楚的时候,就主要把源码和环境弄清楚吧,其它的都是附属品。

    二、从页面到数据库的线

    有了上面的必要条件后,我们就开始了解项目了。由于不只是一个项目,所以千万不能深入具体代码,否则你就越来越烦直到放弃,也不会有好的效果。

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

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

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

    这个整理的过程,主要是让自己梳理清楚,一共有哪些项目,哪些是前端可视的,哪些是后台提供服务的,并且大致了解前端项目分别调用了哪些后台服务。通过后台服务和数据库的名称,我们能从本质上了解到这条业务线提供了什么功能;从前端项目和页面路径,我们能了解到我们需要给用户展示什么。

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

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

    这里关于整理项目部署的机器还有个小插曲,跟大家分享一下。

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

    不要和我说查wiki,如果公司wiki都写的这么全,我估计就没这篇文章什么事了。当时我的jenkins权限特别少,只能看一部分项目,而且还只能执行,不能看配置,带我的人也是抠门,每次问他都给我开通所需要的项目的执行权限,多一点都不给。后来我也懒得问了,由于jenkins机器大家都可以用root权限登陆,所以我进入jenkins的配置文件config.xml,给我自己添加了一个admin权限,重启jenkins,再打开之后屏幕满满的项目都出来了,而且都可以查看和修改,畅通无阻。我就这样通过一个个jenkins的配置,整理了部署的机器,也看了下启动的逻辑。

    三、了解项目间的关系

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

    四、整理数据库表

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

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

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

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

    筛选核心数据表: 如果数据库的表比较少,那我们拿工具导出来表结构,一个个看就行了,这个不难。但如果数据库表特别多,我们首先要将表名全部导出,筛选出那些核心的表。这里导出表名、筛选表以及后面的分析表字段,不妨给自己做个工具,我在遇到一些很麻烦的或者感觉以后还可以通用的事情时,就会做成一个小工具,放在一个我给自己起名为javamate的程序中,这些小工具逐渐积累起来你会发现今后有意想不到的方便。

    判断哪些是核心表: 不要着急,我们首先排除掉一些没用的。拿我在公司分析的系统来说,一共150多个表,其中有好多copy结尾的是备份,flow结尾的是流水,rel结尾的是中间关联表,statistics结尾的是数据统计表,log结尾的是日志表,config结尾的是配置表,等等。排除掉这些对核心业务理解无影响的表之后,所剩的也就20来张表,再根据它们的名字,可以看出好多表是属于一类的,比如order表就有各种order,按类别再分出来也就四五类,再分析起来就不难了。当然如果是更大的体系结构,那就要再不断做拆解。

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

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

    五、整理Controller层接口

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

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

    这里我也给自己做了个小工具,扫描出所有的controller层的接口,展示出方法名、路径名、参数列表和返回值等,但可惜没能展示注释,有大神有想法的话也欢迎帮我想想。

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

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

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

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

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

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

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

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

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

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

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

    这就是我总结的了解项目的过程,我工作年限不多,经验上还不够丰富,希望大佬们多多留言指点,提出问题,共同进步。

    展开全文
  • 研发新人如何快速熟悉新项目和业务

    千次阅读 多人点赞 2020-09-25 10:35:09
    进入一家新公司后,最头疼的就是如何快速了解公司的业务和项目架构。 如果碰到一个特别热心的老员工,事无巨细地给你讲,随时在你身边答疑解惑,那可能还好。但很可惜,我没有碰到这样的人,在加入新公司后,带我的...

    进入一家新公司后,最头疼的就是如何快速了解公司的业务和项目架构。
    如果碰到一个特别热心的老员工,事无巨细地给你讲,随时在你身边答疑解惑,那可能还好。但很可惜,我没有碰到这样的人,在加入新公司后,带我的人几乎没有花时间给我讲项目,也没有给我安排一些可以熟悉项目的需求。就这样的一个多月时间里,我慢慢开始靠自己的力量熟悉大概十个项目,并在过程中总结了一些方法,借此机会记录一下,并分享给大家。

    注意,这里的策略并非快速了解一个项目的具体业务,这个不同项目也不一样,无法总结。
    我的策略是大体了解整个业务线上的所有项目,大概摸清楚每个项目都是干嘛的,他们之间的关系如何,以便以后不论具体负责任何项目不至于找不到方向,具体到细节的业务,虽然需要花时间,但相比对整体上的一头雾水,还是简单许多。

    1 业务的本质

    并非项目面对的客户是谁啊?、项目用的啥框架啊?而是真的能推出所有现存业务的,仅如下两点:

    1. 源码位置(如gitlab)
    2. 部署环境(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中间表,那二者就是多对多的关系,起码从逻辑上讲是这样的。这个分析过程我也是做了个小工具,通过程序来判断的。

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

    5 深入代码层

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

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

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

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

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

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

    通过交互对自身数据库进行增删改查操作:这个无非是最简单的一部分,即使复杂也是代码较长,表较多而已。所谓的交互,或许是Controller暴露给前端用户的接口,或许是开一个rpc端口暴露给其他微服务的接口,总之是第三方去触发的。这里我也给自己做了个小工具,扫描出所有的暴露服务的接口,展示出方法名,路径名,参数列表和返回值等。和数据库一样,如果接口很少那么一个个看,如果特别多,还是先找出比较核心的几个方法研究。这里我用的是postman,把要研究的接口访问保存起来,并且添加访问成功和失败的Example。这里我推荐自己开发的时候也把postman用起来,越详细越好,postman不只是可以简简单单访问你的接口,还能做批量测试,还可以生成api文档用于和前端交互。这样你不但测试了自己的接口,还省的写文档了。而且postman还有个好处就是可以给自己的接口mock一个服务,这样即使你的接口挂了,或者你的接口根本就没写好,你可以让前端人员先访问你的mock,完全不影响前端边测试边开发,这才是真正的前后端分离嘛。整理出所有接口后,肯定大部分是很简单的,一看就懂,一层一层点进去直到数据库层的sql语句,该接口最本质的东西就出来了。如果是复杂的,那就一步一步debug,花时间总是可以分析的。如果再复杂的,你可以画流程图(这里我比较推荐用processon)。甚至几个接口围绕一个功能的,你可以画状态流转图。比如我之前看我们公司处理订单业务这块,逻辑确实比较复杂,我就画了类似如下的具有程序员视角的状态流转图(这里只是示例图):

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

    订单表 order_status 状态流转
    0-待支付 1-已支付 2-已取消 3-退款中 4-已退款 5-退款失败
    支付成功异步通知来了 -->1 报错 报错 报错 报错 报错
    用户发起退款 报错 -->3 报错 报错 报错 报错
    退款成功异步通知来了 报错 报错 报错 -->4 报错 报错
    退款失败异步通知来了 报错 报错 报错 -->4 报错 报错
      接口对表的影响图:这里你可以把所有涉及到的表以及表中的关键字段列举出来,然后看分别调用接口后对各个表字段的影响,变化的就用红色标出

    有了这两种维度的视角,我相信再复杂的业务都能很理清楚,也能发现某些bug最本质的问题。我正是通过这样的方式,把一个本来不属于我的项目短时间内了解清楚,快速准确地修复了好多顽固的bug。虽然项目很烂,业务逻辑十分混乱,但正是这样一段时间锻炼了我深入代码理清逻辑的能力,也有了自己独特的一套方法。

    通过定时任务或服务器脚本对自身数据库进行增删改查操作:这个和第一种类型一样,只不过换了个 入口。如果有些问题你发现并不是交互而产生的,那你就要寻找其他入口。比如定时任务,或者启动的时候就开启的一些线程。寻找这些入口的确不是特别容易,比较头疼,但也只是入口比较隐蔽而已。找到他,记下来,具体分析过程还是按照上述方法去分析,就可以了。

    调用或通知其他服务做一些事情:上述两种代码如果你都摸得差不多了,整个项目对自身的玩法基本你已经摸透了,那还剩一小部分就是它和其他服务之间的交互。代码中一定有通过mq给其他服务发消息,或者直接调用其他服务的接口,或者调用类似云推送的接口让它去帮忙像mq发消息。总之不管形式如何,都只是为了rpc其他服务而已。这部分代码可能更加隐蔽,但数量少,逻辑也简单,你需要做的仍然只是找到它们。这部分也是为了解项目之间的关系打下伏笔。

    这三种类型的代码研究清楚后,对于一个业务型的项目来说,已经基本足够了。对于一些基础服务和中间件类型的服务,还是得慢慢积累技术深度才行,了解过程仍然也是可以有规律的,只不过需要更底层的方式去分类,比如将代码分成资源的加载,模式的匹配,等等。由于本篇文章是快速了解一个业务型的项目,所以就不展开叙述了。

    6 重新理清项目间的关系

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

    根据之前的接口名称,详细了解下项目间的调用关系。理不清的部分去问老员工,这时候你带着自己的了解问,他们也能给出更多的信息。
    看看每个项目中用到的中间件,主要是mq服务,看看谁是生产者,谁是消费者,以此来了解关系
    这时你应该已经开了好几轮的周会了,接下来的周会你应该能听懂部分内容。根据每个人的描述和最新的几组需求,逐渐摸清楚现在项目面临的问题,以及哪个项目是核心,哪个项目是辅助,哪个项目是以稳定安全为主的

    到此为止,整条业务线你就有了大致的了解,接下来就要结合你具体负责的内容,领导安排你做的方向,去看具体的业务代码了。深入其中,事无巨细地了解。但此时,你通过前面的努力,你已经可以站在一定的高度看每一个项目了,虽然你细节上还是不了解,但这是完全不同的。在研究具体业务代码的同时,不断地跳出来看整条业务线的框架,修正之前由于不了解具体业务而理解错误的架构。长此以往,你一定会在某个项目中脱颖而出,让大家认识到你的全局视野,这也是走出老是写增删改查代码怪圈的一个途径。慢慢会有人意识到,你对项目的理解总能站在全局的视野,很多需要跨项目去做的业务,也会自然而然想到你,慢慢地,你会接触到更为核心的东西,成为架构师,或者去转向产品,转向管理。

    参考

    • https://www.cnblogs.com/flashsun/p/9450066.html
    展开全文
  • 测试人员如何快速熟悉产品业务

    千次阅读 2020-02-27 08:00:00
    针对人员软件测试行业小白、业务短板群体针对项目中问题点1.项目中完全就没有统一标准的文档可查阅2.项目中文档内容缺失不规范或(产品人员时间上紧迫)文档更新不同步以企业管理学习系统为例,系...
  • 快速熟悉项目代码

    千次阅读 2019-03-30 07:59:55
    快速熟悉项目代码1 背景2 方法2.1 通读需求文档,了解项目用途2.2 熟悉开发工具、常用功能2.3 部署环境,把项目跑起来2.4 看项目结构2.5 展开项目目录2.6 浏览文件2.7 选切入点2.8 尝试添加功能或者修复bug3 注意点...
  • 如何快速熟悉项目代码

    千次阅读 2017-02-17 17:34:31
     项目交接、加入 新的项目团队,需要快速熟悉项目 1、全局观 要有整体意识    熟悉 业务需求 ,此系统 是 给谁用的(哪些用户),将系统拆分 子系统,子模块,其作用(是干啥的)   2、
  • 作为一名新近公司的运营或者业务员,老板或者经理会先让你学习产品知识,如果连产品都不熟悉,是无法正常开展工作的,那么应该如快速熟悉产品呢? 先看看一般公司的做法: (一)用公司的产品画册,一个产品一个产品...
  • 那么相对面临的问题就是遇到一个新的项目,那怎么去快速熟悉上手这个你不熟悉的项目呢?本人最近公司安排去上海接手1个项目,在这个过程中自己的想法和问题进行一个记录。 一、需求文档、设计文档必须掌握(我们要...
  • 如何快速熟悉一个项目代码 技术角度 1,查看错误。通过show view -> show problem定位每一个错误。解决掉。一个经验和教训。 2,调试跟踪 一个经验和教训 3,查看调用继承关系,即 call hierarchy。对方法和...
  • 作为一个测试如何快速熟悉新项目

    千次阅读 2020-09-06 21:10:10
    (what)对于测试来说,从产品的角度去思考熟悉产品对于快速熟悉测试系统的业务流程是很有必要的。 (why)在如今敏捷开发及迭代快速开发模式下。对测试的效率有着越来越高的要求,因此可以做以下操作: 工作第一...
  • 刚加入公司,如何快速熟悉公司项目并快速上手 几天前我的同事Richard问我我是如何做到在Lumi迅速上手开始自己的工作的,这是一个很好的问题,当我来到这里的时候,从第二天开始我就做了大量的工作(在我的第...
  • 如何快速熟悉一个系统

    千次阅读 2020-04-03 11:36:38
    前言 开发人员经常会面临下面一些场景: 新人入职,需要学习已有系统,作为 landing 的一部分,如何学习?...这样的场景多了,就需要去梳理常见问题以及应对方法,方便后续遇到类似场景可以快速应...
  • 项目测试第二步 - 快速熟悉项目

    千次阅读 2018-12-27 08:59:43
    熟悉   一般   不熟   2 对项目有全局认识   3 编写测试范围列表 测试范围列表示例: 需求编号 功能名称 测试类型 PATH 优先级 ...
  • BA业务分析快速指南

    2018-06-02 04:24:47
    BA业务分析快速指南。
  • 新人如何快速熟悉一个新项目

    千次阅读 多人点赞 2019-06-13 11:22:43
    很多新人进入一家新公司后,最头疼的就是如何快速了解公司的业务和项目架构。 因为文档很少,没有文档,或者是文档严重落伍, 根本没法看;如果你碰到一个特别热心的老员工,事无巨细地给你讲,随时在你身边答疑...
  • [b]技术角度[/b] 1,查看错误。通过show view -> show problem定位每一个错误。解决掉。一个经验和教训。 2,调试跟踪 一个经验和教训 ...3,查看调用继承关系,即 call hierarchy。...熟悉业务 ...
  • 如何快速熟悉一个新的软件项目?

    千次阅读 多人点赞 2018-05-11 11:40:40
    我们会经常遇到一些新来公司的大牛,在短短是一两周就可以熟悉公司的业务和技术了,而且还能熟练的辅导比他更早来公司的小菜鸟了。 什么原因呢?因为他们已经从以往的经验中总结了一些套路出来了。上套路 1、绝大...
  • 灵魂 36 问,让你快速熟悉一个系统

    千次阅读 2020-04-14 16:43:26
    简介:面对一个完全陌生的系统,如何快速熟悉并上手?本文将从三个方面进行总结,提供一个系统的方法,同时也可以用来 review 已有的系统,查漏补缺。 前言 开发人员经常会面临下面一些场景: 新人入职,需要...
  • 程序员如何快速熟悉一个系统?

    千次阅读 2017-03-12 14:48:06
    1 浅入了解:点点页面,快速熟悉系统功能点。 点点这个系统的页面,大致了解这个系统的功能,知道这个系统是干什么用的。为谁服务的。在熟悉页面功能的时候,可以找产品问,可以问以前的开发,可以问测试;这个...
  • 项目都不知道是干什么的,千万不要一开始就选择看代码看技术,项目的技术往往是结合业务相关联的 1.公司入职java,前3天或前一周,正常来说是不会接手开始做项目。达环境配启动项目,不要浪费太多时间,最多半天...
  • 如何快速接手并熟悉新项目

    千次阅读 2018-09-05 17:28:30
    此次接手的项目是某app的一个子模块功能,我通过以下几种方式熟悉业务. >翻阅曾经版本的需求文档,产品原型图,UI设计图也有有个大致了解 >询问测试人员,测试组的妹子,对业务的熟悉程度,超乎你的想象. 2.熟悉...
  • 如何快速理清大型项目业务逻辑

    千次阅读 2018-10-18 18:21:16
    本篇文章为了探讨如何快速上手一个大型项目。针对经验尚浅需要快速接手一个项目的开发人员。 当他们拿到一个大型程序后,他们便开始一句一句的阅读分析,夜以继日,悬梁刺股。可结果依然不理想,往往进入以下状态:...
  • 如何熟悉一个系统的业务逻辑

    千次阅读 2007-09-03 09:22:00
    对于一个新手来说,要熟悉一个系统的业务逻辑,除了要多运行这个系统之外,还应该注意理解:系统的基础设置在系统的业务逻辑中的关系及体现。只有熟悉了这一点,才算是真正了解了这个系统的业务逻辑。
  • banner.txt 启动的炫酷图标 3,resources -> templates下看静态资源 三,java代码 1,controller 控制器(不做业务代码,仅仅实现调用) 1. 接口 @RequestMapping("/api/admin") 2. 接收请求 @PostMapping("login")...
  • 商业转载请联系作者获得授权,非商业转载...对刚开始入职的新人来说,刚开始一定是先从公司业务框架和业务流程学起,这个时间段需要做的就多看,多问,多做。 01 多看 多看指的是多看公司需求文档,需求文档包括任...
  • 先了解项目目标及整体需求 如果有原型,就先熟悉原型用PD看表之间的关联关系,判断业务需求了解项目所用框架及相关技术了解模块划分(WBS)然后就是再代码了
  • 程序员如何快速上手一个自己不太熟悉的新项目 在知乎上看到的,由作者Jim Jin(奔四老码农,只想做点有意义的事情)写的。 原文出处:http://www.zhihu.com/question/38865497/answer/78625125 作者:Jim Jin...
  • 使用bootstrap和application两个设定文件来进行相关设定,入门时为了更加快速,使用最少的设定文件和设定语句,基本上只有不可或缺的才会加上,入门之后详细内容参看spring cloud官方文档即可。application....

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 103,963
精华内容 41,585
关键字:

如何快速熟悉业务