欢迎光临
我们一直在努力

程序员随想-快速熟悉业务


前言

作为一名开发,经常面临着主动或被动切换业务做,有些时候切换至有一定相关联的另一个业务,本来做余额宝的被调到做证券。一些情况下是切换至完全相关的业务,如从商品切换到交易,甚至从电商业务切换至金融业务。在经常遇到这种的情况下,建立一个“快速熟悉陌生业务”的方法论就很重要了。下面经过个人思考,提出的一些不完善的想法。

一、划分模块

人的记忆和关系型数据库有些类型,较容易记住的大的关键点,而具体的细节可能想很久,甚至记不住。根据人的这种记忆方式,我们接触一个新的事务最好的方式应该就是分层,按照一定逻辑分几层,每层分多个模块,了解每层各个模块概念,然后再细分下一层子模块概念。这种思维方式有点像数据库的索引,符合人的思维习惯。

划分模块方式

模块是基于一定逻辑组织形式来划分的,只要按照逻辑来划分的话,划分模块的方式肯定有很多种,这里我提两种最容易的方式:业务功能,应用架构。

业务功能

按照业务功能性,对业务进行拆解,把复杂的业务进行拆分成功能单元,各功能单元再根据场景进行更细粒度的拆分。拆分有一个原则,要做到高内聚,低耦合。

image.png

应用架构

基本上应用都是分层的,下图就是最常见的应用的组织形式,当然很多应用组织形式会根据具体情况进行变化

image.png

二、梳理业务领域模型

对于大部分人结束新的业务的时候,相信最麻烦的就是周围人谈论的“专业词汇”,像之前听得什么,直销、代销,转托管,卡账,户帐这类词汇对于第一次听到人肯定蒙蔽。对于这一类词汇其实很多都是特定业务领域形成的简化术语,如果连这些业务领域内的概念的不清楚,那么根本不知道在讨论一个什么事。这类词汇存在于特定业务领域中,了解业务领域是相当重要的,统一大家的概念认知,统一大家在讨论的是一件什么事,在做的是一件什么事!!

所以我说的要了解业务领域,并不是指得DDD,充血、贫血模型。而是对业务进行一定抽象成一个或多个有关联的业务模型,对于这个模型有一定认知是需求讨论和方案设计的前提,很多时候某个业务域用到了其他业务域的模型,那么相对于相关联业务域的模型也要有一定认知。

如何梳理业务领域模型?

业务领域模型最底层的是数据库表极其字段,把表和表之间的关系,字段含义理清楚后,会有大概的业务轮廓。接着通过熟悉模块中核心的POJO的类极其字段能更对业务有更清晰一点的认知。当然这还不够,还需要花时间去看一些集团,网上的文章,关于其他人对业务的理解,其他人在技术如何设计和实现的。这个过程不是一蹴而就的,慢慢的会找到更深的理解,等到了能发现当前这个业务领域模型优点缺点,并构思出改进的方向,基本上就意味已经进入这块业务领域的专家了。

三、梳理业务调用链路

寻找业务入口,然后看代码。一般来说业务代码迭代很快,很多在写代码的时候没有考虑以后,经常被之后的需求给推翻调,亦或者经历过多个团队多人接手过,每个人命名、设计等等习惯不一样,所以这个过程比较痛苦。

如何梳理业务调用链路?

这里必须要提一下,traceId是个神器,自己实际操作一笔拿到traceId,在集团鹰眼或者蚂蚁云图上应用的调用链路基本上呼之欲出,但是具体逻辑细节还是要自己去看代码。这里看代码我理解两种模式,一种是自下而上,另一种是自上而下。我比较喜欢自上而下的看,这样顺着业务链路来理解比较简单,大部分情况下两者结合效果比较好。

自上而下

前后端不分离的PC页面,顺着页面实际操作入口去看,很简单前后端分离的PC页面、Ajax接口、无线端,和前端同学打好关系,多聊聊,喝喝咖啡,让前端同学帮忙去找入口,另外就是通过网络抓包找到调用入口,顺着代码往下看吧,少年。通过日志里面的traceId可以查到调用链路甚至到接口级别,这就更方便找到入口。一般情况下相同功能模块、对外的接口会放在一个大包或者pom模块下面。

自下而上

从数据库表入手,理解表模型,各字段含义,建立各表和字段之间的关系。

四、需求入手

一般情况下,公司不太会给太多空闲时间去看代码,且直接看代码多数情况下也没有那么直观感受,这时候结合一些比较完整的需求去搞,效果反而会更好。所谓完整的需求是指:尽量是完整模块的需求,或者能串联部分或整个链路的需求。切身体验零散的需求没有鸟用。

未经允许不得转载:ITyet » 程序员随想-快速熟悉业务

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
打开看板娘