我們一定會遇到這樣的情況：就只改了一行代碼，只用對這個改動的地方回歸下就好了，為什么上線的時候影響到了其他的業(yè)務需求了？
在解決上面的問題之前，我們先簡單做兩個問答題吧：
問題1：如果兩個業(yè)務操作的數據載體不會有交集（包括增刪查改），這兩個業(yè)務在系統(tǒng)上會相互影響嗎？
問題2：如果兩個業(yè)務操作的代碼寫在兩個完全不同的地方（代碼上沒有交集），這兩個業(yè)務會相互影響嗎？
對于數據業(yè)務型系統(tǒng)，我現(xiàn)在還沒有遇到兩個數據載體沒有交集的業(yè)務操作會相互影響，如果大家有例子，可以分享下哦。
如果兩業(yè)務代碼上沒有交集，那我們完全不能保證他們業(yè)務上不會互相影響了，大家可以看下下面這張圖。
注：這里的數據實體，即數據的載體。
同一個數據實體，會面臨不同業(yè)務需求的操作，每個業(yè)務對該數據實體的操作范圍會不同，但是數據實體中數據的變更會對業(yè)務造成影響。往往這些影響，局限在本業(yè)務范圍內是發(fā)現(xiàn)不了的，一些暴露出來的缺陷，反而會讓人感覺時現(xiàn)時不現(xiàn)（因為只是部分數據被其他業(yè)務修改了），很多同學會聯(lián)想到是不是并發(fā)之類的問題導致的。其實如果跳出這個業(yè)務范圍，站在全局的角度，就很容易發(fā)現(xiàn)問題。
所以我們經常需要回歸測試，我們現(xiàn)在有大量的回歸腳本支持回歸測試，但是某些缺陷是無法通過回歸腳本發(fā)現(xiàn)的，往往需要我們通過對業(yè)務的嗅覺，進行回歸點的挖掘，來實現(xiàn)對缺陷的預防。
下面舉一個現(xiàn)有回歸腳本無法發(fā)現(xiàn)的缺陷：
前提：業(yè)務一的開發(fā)早于業(yè)務二
（業(yè)務二）對某一實體進行修改操作，該改動涉及到一個（業(yè)務一）同樣關心的字段。
（業(yè)務一）對該實體進行查詢操作，在解析上面的字段時，由于無法解析而報錯。
在單純對業(yè)務一的持續(xù)集成腳本的維度來說，無法解析的屬性，應該是要報錯的，這個異常流程走的很對。
所以如果單純從之前的回歸腳本進行回歸而判斷這次修改是否影響到了之前的邏輯，是武斷的。
同樣依靠同學們對業(yè)務的熟知度，來挖掘業(yè)務二對業(yè)務一的影響。這種做法并非科學，任何一種完全依靠人腦來做決定，是會有遺漏的，是有風險的。
再舉一個例子通過查代碼去發(fā)掘回歸點可能遺漏的例子
如何發(fā)現(xiàn)一段代碼的影響范圍，大家是不是做過去看下這段代碼將會被哪些代碼調用，即對應的下游代碼。無疑這么做確實可以發(fā)現(xiàn)同一流程下的影響點。但如果不在一個流程里面呢？如果相關同學對將會影響到的業(yè)務其實并不熟悉，該怎么辦？
我們就需要一張大圖，一張業(yè)務邏輯大圖。這張大圖的組成為實體+沉淀+入口。
為什么要做這張大圖，這張大圖是什么樣子的？
我們的系統(tǒng)是基于MVC模型，通俗說法就是通過V調用C去操作Ms（因為M可能很多，哈哈）。所以歸根結底，變化的是M，影響的也是M。
M，即Model，它主要與數據載體交互的功能。我們將與M交互的數據載體，稱為實體。
沉淀，即業(yè)務沉淀，即對應的功能點的IO與控制器的綜合體，是業(yè)務的精華。
入口，就是記錄入口在哪里，方便區(qū)分業(yè)務。
如果我們有了這樣一張大圖，同一個實體被多個業(yè)務使用到，我們可以輕松得通過實體反向抓取出對應的業(yè)務，然后通過對業(yè)務沉淀的分析，獲取相應的功能影響點。
這張圖，我們需要一個好的載體，這里選擇MM圖。下面我做了一個簡單的示例：
其中用了幾個標簽：t 功能點標簽；a 業(yè)務沉淀標簽；e 實體標簽；l 入口標簽。
標簽的好處就是在編寫完成之后，可以方便得進行數據提取，進行業(yè)務分析。
MM圖化有什么好處呢？
1、大容量
可以把一個系統(tǒng)，甚至一條業(yè)務線的業(yè)務整理到一個MM圖里面。
2、樹狀結構，方便業(yè)務梳理
3、規(guī)范化編寫
規(guī)范化編寫，可以方便利用工具進行提取，也方便人工閱讀和挖掘。
業(yè)務沉淀圖形化，規(guī)范化，對后續(xù)的回歸和業(yè)務變更會帶來很多好處，也會對回歸點的判斷上，做出更加科學的判斷。
精準回歸，核心在業(yè)務層面，是對業(yè)務的充分理解和剖析，是對業(yè)務的有效管理和挖掘，但是我們可以在技術層面上為這一系列管理更加高效而實用，大家可以繼續(xù)關注后續(xù)的博客哦。