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

前言

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

1、划分模块

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

划分模块方式

模块是基于必定逻辑组织形式来划分的，只要按照逻辑来划分的话，划分模块的方式确定有不少种，这里我提两种最容易的方式：业务功能，应用架构。

业务功能

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

应用架构

基本上应用都是分层的，下图就是最多见的应用的组织形式，固然不少应用组织形式会根据具体状况进行变化

2、梳理业务领域模型

对于大部分人结束新的业务的时候，相信最麻烦的就是周围人谈论的“专业词汇”，像以前听得什么，直销、代销，转托管，卡帐，户账这类词汇对于第一次听到人确定蒙蔽。对于这一类词汇其实不少都是特定业务领域造成的简化术语，若是连这些业务领域内的概念的不清楚，那么根本不知道在讨论一个什么事。这类词汇存在于特定业务领域中，了解业务领域是至关重要的，统一你们的概念认知，统一你们在讨论的是一件什么事，在作的是一件什么事！！

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

如何梳理业务领域模型？

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

3、梳理业务调用链路

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

如何梳理业务调用链路？

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

自上而下

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

自下而上

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

4、需求入手

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