最近在接手老唐的結算任務部分代碼，代碼的複雜程度本來已經有心理準備，但是等把代碼拿到手並仔細看進去後才發現我的心理準備是那麼的脆弱。。。
且不說老唐爲這份代碼準備的流程圖，兩個核心大流程，兩個核心流程中的核心功能塊，這裏也不打算對具體業務流程做介紹，只用一幅流程圖來說明其複雜程度（該流程圖只描述了部分核心流程）
由於幾乎圖上每個流程框都是一個非常複雜的方法，並且還分佈在不同的類當中，這就牽扯出一個問題，當前計算的數據保存在哪？或許這個問題還比較抽象，具體到一個實際的例子吧。在對某商品的購買記錄做結算、分成時不能對每個訂單都存一遍結算、分成數據，而是要將結算結果累加到一起後再做分成，等把所有商品遍歷完了後再統一調用支付寶接口進行轉賬。那麼在這個過程中，如果記錄累計的結算、分成，以及支付寶接口調用的數據呢？下面是一個簡單的內存數據結構草圖
其中SettleDetailMap是一個以商品id做主鍵的HashMap，用於記錄不同商品的結算數據，也就是SettleDetailContext了，這個SettleDetailContext是一個複雜類型的數據對象，裏面放有累計結算金額，支付寶轉賬的本地數據，累計分成金額和若干控制程序扭轉的標誌參數等，這樣對不同商品進行結算時就從SettleDetailMap對象中獲取該商品的上下文信息，完成結算、分成後，將金額累加到對應SettleDetailContext的子對象中。。。等到所有商品的訂購信息都被結算完了，最後才遍歷SettleDetailMap，完成支付寶轉賬等操作。
上面簡單介紹了上下文在結算系統中的應用，當然實際情況比這個上面描述的複雜的多，但是終究思想就是把所有數據按某一個原則劃分（如appid），然後在內存中保留所有待處理的數據對象，並在需要的時候取出。
思考：
記得一個前輩曾經說過，如果一個系統的實現代碼異常複雜，那麼設計一定出了問題。的確，別的不說，就這套代碼的上手難易程度來看，絕對屬於S+級，業務流程還可以用普通流程圖描述，內存數據的變換那真是完全無法描述了，我很多時候都是靠debug看內存狀態來理解其內存數據的變換的，那麼是否有好的辦法來理解、描述這種複雜的內部數據場景呢？真的只能靠上下文的傳遞嗎？