最近線上測試，發現有2個C（概率復現，對玩家沒什麼影響）級BUG給到我，雖然一直也有出現，但沒找到原因。因昨天打包電腦換工位，外面也颳風下雨。宅在家寫點內容。小結下最近看到自己所犯的錯誤。
一、線上C級BUG
表現：可領取的特效沒顯示，顯示上2/2,也沒顯示已經領取的打勾顯示
分析：看到單子的那一刻，我分析下，我覺得邏輯上，加載對應的特效的肯定沒寫錯。那方向鎖定了特效的被UI的層級內容擋住了。看了下是SortingOrder出錯了，看了之前的代碼，當時爲了方便還特地取了當前的界面的canvas,但是獲取地方錯了，因爲在設計上延遲卸載會有UI層級的重新排序。如果放在Open函數中就能決解問題的。
解決方案：在要加載的Node界面中，獲取當前打開界面的View，再獲取Canvas。規避因UI排序的造成的影響，也讓代碼可讀性提高了。明確這個Node是哪個View的子節點。
二、賽季獎勵界面，低概率報錯
策劃需求，2個PVP活動，要支持熱更新，要支持配置多個賽季
程序設計上：一張表分爲2個部分請求，一次是框架表的內容，一次是用id關聯具體的獎勵信息。有依賴關係和先後關係。
表現：有時有的新帳號，打開界面報錯。
第一次QA報告過來，覺得是配置問題，讓服務器查了配置解決發來的部分是沒問題。我覺得是初始化的問題。加了對應的代碼保護，作爲一個低概率復現的bug給了QA。QA把單子關掉了。
第二次QA報告過來，Unity可以復現這樣的表現，但QA復現的情況是，在修改服務器時間（切換賽季的時候出現）。再切換服務器時間，又不復現。
有點陷入困局。邏輯上沒問題，函數初始化也做了保護。看到一行UIScorllView的報錯，傳入數據是null的話，是收到服務器返回協議的時間不對。加了收到兩條協議的時間打印。驗證我的思考方向，時間打印順序不對。一般來說都認爲服務器協議是隊列的，先進先出。這兩條協議和服務器交流下來，因爲第一條協議內容更多，回來的慢一點。
決解方案：在兩條協議都確認收到後刷新界面。
三、開蛋的動畫停的幀不對
UE需求：三個蛋分別在不同時間裏晃動，0-3、3-6、6-9；
在一個蛋播放完砸開的動畫後1s,其他2個也播放砸蛋動畫
表現：第三個蛋的砸蛋動畫，所停在幀是不對的
分析：播放動畫和動畫樣的代碼都沒問題，還找同事幫忙確下動畫相關的代碼沒寫錯。第二天有找另一位同事幫忙看。是協程的問題的。
我個人習慣覺得StartCoroutine(method())比StartCoroutine(“method”),在代碼友好和可維護上比後者好。誤認爲對應的停止函數StopCoroutine(method())和StopCoroutine(“method”)，其實前者這方法是錯誤的，並不能生效。
決解方案：用StopAllcoroutines()有點粗暴。
正確的寫法是
coroutine mCoroutine = Startcoroutine(method())；
StopCoroutine( mCoroutine);
看官方API
public Coroutine StartCoroutine(IEnumerator routine);
public void StopCoroutine(string methodName);
public void StopCoroutine(IEnumerator routine);
public void StopCoroutine(Coroutine routine);
用的時候沒看，有點想當然了。
四、龍玉升級當從1級直接升級到9級龍玉的時候會出錯
表現：從1級直接合成9級龍玉，顯示上扣除數量是對的，但報錯了，服務器判斷不能升級，並把龍玉扣掉了。如果重新登錄，對應扣掉的龍玉又返還回來了。
分析：客戶端顯示的計算是沒錯，服務器在返回失敗的情況，不應該扣除龍玉。QA復現，服務器定位收到協議數據，我發過去的數據計算錯了。
解決方案：爲嘛在升9級時候報錯，因一種龍玉的最大堆疊數爲999,而升9級的超過了，跨堆計算數量的時候，數值減錯了。
反思：之前寫過類似的代碼代碼優化,不請記得自己當時是什麼狀態，但確實不夠細心。還是非常感謝QA耐心幫忙測試。對於線上版本影響不大。挨個試，才確定了復現方式。
五、組件的顯示不對
表現：根據陣營不同，對應特效的不同節點顯示和隱藏。
分析：收到的數據是有沒有出錯的，分析原因是組件和數據之前關聯，那一步出錯了。
目前也沒有定位到具體問題出在了哪裏了。
下週繼續死磕了。
更新 : QA後來穩定復現異常的情況。在FadeIn的時候，字典處理當時沒理清楚。
處理前的代碼
if(value!= NUll &&!Dic.ContainsKey(key)
{
Dic.Add(key,value);
ChangeEffect(key,value);
}
處理後的代碼
if(value!= NUll)
{
Dic[key]=value;
ChangeEffect(key,value);
}
完美解決問題了。
反思：通過打印日子看逐步Log才確認問題了。dic加新Key之前先判Key後加入，確實之前養的好習慣。主要還是缺少對於這個地方返回出現FadeIn的情況理解。
六、總結
工作中都會犯錯，但通過覆盤讓自己減少犯同類似的錯誤，來最大化提高效率。從過去的經驗中學習，形成自己遇到新問題解決的方式。
例如重新這個情況，卻有三種不同情況出現。一種是卡頓重連，一種是下線重連還有一種是頂號換端重連。