再举一个例子通过查代码去发掘回归点可能遗漏的例子
如何发现一段代码的影响范围，大家是不是做过去看下这段代码将会被哪些代码调用，即对应的下游代码。无疑这么做确实可以发现同一流程下的影响点。但如果不在一个流程里面呢？如果相关同学对将会影响到的业务其实并不熟悉，该怎么办？
我们就需要一张大图，一张业务逻辑大图。这张大图的组成为实体+沉淀+入口。
为什么要做这张大图，这张大图是什么样子的？
我们的系统是基于MVC模型，通俗说法就是通过V调用C去操作Ms（因为M可能很多，哈哈）。所以归根结底，变化的是M，影响的也是M。
M，即Model，它主要与数据载体交互的功能。我们将与M交互的数据载体，称为实体。
沉淀，即业务沉淀，即对应的功能点的IO与控制器的综合体，是业务的精华。
入口，就是记录入口在哪里，方便区分业务。
如果我们有了这样一张大图，同一个实体被多个业务使用到，我们可以轻松得通过实体反向抓取出对应的业务，然后通过对业务沉淀的分析，获取相应的功能影响点。
这张图，我们需要一个好的载体，这里选择MM图。下面我做了一个简单的示例：
其中用了几个标签：t 功能点标签；a 业务沉淀标签；e 实体标签；l 入口标签。
标签的好处就是在编写完成之后，可以方便得进行数据提取，进行业务分析。
MM图化有什么好处呢？
1、大容量
可以把一个系统，甚至一条业务线的业务整理到一个MM图里面。
2、树状结构，方便业务梳理
3、规范化编写
规范化编写，可以方便利用工具进行提取，也方便人工阅读和挖掘。
业务沉淀图形化，规范化，对后续的回归和业务变更会带来很多好处，也会对回归点的判断上，做出更加科学的判断。
精准回归，核心在业务层面，是对业务的充分理解和剖析，是对业务的有效管理和挖掘，但是我们可以在技术层面上为这一系列管理更加高效而实用，大家可以继续关注后续的博客哦。
