第一屆開發者寫作松，軟體工程師軟實力系列第五篇
有資料串接就有可能掉資料，掉資料時的處理方法，就跟水管找漏水一樣，像偵探一樣沿著線索找下去。
問題處理起來像推理遊戲。
案發現場
身為最接近使用者的前端介面，ＡＰＰ經常會是發現問題的起始點。
通常我會依照特定“辦案”步驟找元凶：
- 先看看自己程式碼，該印出來的該檢查的欄位都先檢查一次，免得繞了一圈才發現問題是自己就囧大了。
- 如果有對接那頭的相關工具，就使用工具協助測試串接流程，例如Postman或LightBlue，建立假資料有助於釐清自己的清白。
- 欄位名稱大小寫、型別、長度範圍核對都沒問題的話，就要先切割流程了。
- 將流程詳細劃分後，先排除問題出在自己流程內的可能性，接著就是兩頭對測看Log。
流程劃分
將原本串接的流程詳細分成更多階段。
例如硬體藍芽串接流程：
或者APP Webview串接：
友善互動
雖然說是”辦案”，但如果每個接口都說自己那端沒問題，就永遠找不出問題，因此友善積極的合作偵錯才是該有的心態。
解決串接流程問題，而不是演變成責任推卸的過程。
串接經驗
即便心態對了，也在每個階段排查了，還是找不到問題原因？
很多時候難以排查的問題都發生在原本預設不會出問題的地方，例如WKWebview不支援某些特定的UI元件、底層應該送出去的資料卻被攔下了，錯誤發生在原本認為不會進去的handle，或者根本就沒有handle錯誤。
列出各種可能性
手機型號、系統版本、記憶體、時間、執行緒、髒資料，把有可能造成問題的情況都列出來一一排出嫌疑。
排除不確定性保留單一變數
前輩最常建議我的方式是開一個空專案，用乾淨的環境測試，但十個工程師九個懶，第十個特別懶，因此我都偏好直接在自己專案裡面註解其他功能保留單一項目來確認問題，真的萬不得已才會開空專案，沒錯我就是特別懶…..
但另一個原因是，開空專案也不見得找得到問題，因為環境和變數太多了，反而要複製相同的環境也是成本，不如直接在原專案排出多餘的影響。
善用Log
針對時間、順序去分析Log，是我覺得最簡單方便的偵錯方式。
IOS app開發介紹 — IOS一些重要的概念與機制(9. 了解與分析App Crash Report)
但是，問題不見得都是靜態的，不是每次都會發生的突發性問題，不見得這樣就能解決，因此最後還是得走到會議室裡對測。
責任劃分清楚，更能有效處理問題，自己管好自己的事。
解決問題然後呢？
通常大家在解決問題時都會問Google大神，但如果查不到或者解決方式都很片面，就必須再費一番功夫研究，所以我會建議把解法和經驗留下紀錄，不僅自己下一次遇到類似的問題就有依據，就算不是金魚腦也很難在兩三年後還記得當時的細節，而且還能與團隊分享避開地雷，專心攻打下一座城堡(下一個坑)。
取之於社群、用之於社群。
結論
每個地方都有可能出問題(有嫌疑)，但真相只有一個！
