背景
如果工作中涉及到很多的模塊但是由于數據沒有閉環導致測試的時候提出一些數據不一致的bug。
比如系統各個模塊中統一為一個邏輯整體，但是沒有做數據同步導致出現數據不一致。對于實現細節的人可以立馬想到原因是什么？但是對于產品或者測試來說，他們的腦子里認為這是一個邏輯整理，我在其中一個模塊是可以看到記錄但是與其他模塊交互的時候為什么不存在，腦中自洽的邏輯被打破了。
工作中具體的例子
我司CRM客戶、互聯平臺企業、訂貨通客戶是一個邏輯的整體，他們的鏈路關系式 CRM客戶 -> 互聯平臺企業 -> 訂貨通客戶，即互聯平臺企業邏輯上來自于CRM客戶，當然可以直接在互聯平臺創建企業（同步在CRM創建客戶），訂貨通客戶來源于互聯平臺企業。所以當CRM客戶被刪除的時候應該刪除互聯平臺企業和訂貨通客戶 。
但是由于CRM是北京團隊做的，他們沒有做數據同步操作。當然很多模塊都依賴于CRM的業務，北京CRM團隊可以發送客戶刪除的mq消息來通知很多團隊來同步數據的。
沒有做數據同步導致測試的時候不理解，為什么訂貨通客戶還在缺報客戶不存在呢？其實是調用北京的接口提示說不存在的。這樣的不一致在一定程度上降低團隊的效率，會出現很多這樣的數據不一致的bug都需要去跟蹤耗費時間。
數據要同步且最好只有一條渠道來同步
在互聯平臺與訂貨通客戶之間有一個mq消息來同步，但是當時小伙伴認為mq消息不靠譜，在查詢query的時候比對了一把把不一樣的刪除了。
直到有一次上線出現過這種情況，客戶命名同步了訂貨通的可見范圍且賦予了權限，但是就是看不到訂貨通的聯系人。通過查日志才知道是在查詢語句里被刪除了。
這里的場景就是數據同步有兩個地方，而另外一處是當時對于mq不信任寫的是在測試、產品、客戶可理解范圍之外的。他們不會想到query的時候也會比對一把同步數據沒有這樣的邏輯。所以從這一點來說我們寫的代碼實現的功能應該是符合上層的邏輯，上層的邏輯最好的校驗就是產品和測試。
所以數據要同步且應該符合邏輯最好只有一條渠道來同步。
