最近處理一個關於短信的問題，debug過程中有遇到一些障礙和彎路。問題是手機應該收到一條語音信箱的短信，但是一直沒有收到。Modem已經上報了短信的PDU，但是framework解析之後進行dispatch失敗了。對PDU的decode和dispatch都是Google AOSP的，第一感覺應該是framework應該沒有問題，應該是PDU的格式不符合spec造成的，使用工具解析PDU後並沒有發現什麼問題，又回到error的地方，發現是一個service處理的PDU，這個service可以客戶override，所以就馬上懷疑應該是客戶override的這個service出現的問題，service處理的PDU已經是framework decode後的user data了，但是service依然用這個數據create PDU，導致判讀長度失敗了。發現問題的根本原因後，當時就準備給客戶一個temp patch，解決掉這個問題。在準備給客戶詳細的問題原因和temp patch的時候發現，對於正常的WAP PDU短信應該走不到出現error的地方，就又重新回到解析PDU的地方，發信原來這個PDU的teleservice id是WAP PUSH的，但是dest port不是，導致不能正常dispatch，而進入了正常短信的處理流程，而WAP pdu的處理和普通短信是不一樣的。問題發信後，只能請底層的owner來查看問題了，是PDU的teleservice ID不對還是dest port不對。
如果對短信模塊不熟悉，沒有關係，問題其實就是如何確定問題發生的點，以及如何寫code，是讓問題儘快的暴露出來，還是做一些error handling讓問題不發生在自己負責的模塊裏面呢？這個短信的問題，其實底層就可以check出當前的PDU是否符合spec，如果不符合spec就不要上報，打出爲什麼沒有上報的原因，這樣問題就會很容易查找。但是底層是直接把PDU發送給framework進行處理，而framework是處理不下去了，纔出現的error，而從error出現的地方就很難知道爲什麼會出現error，爲什麼會走到這裏。如果對code不熟悉，可能會添加一些error handling，讓代碼正常運轉，但是真實的問題點可能就會掩蓋掉，甚至問題只是不發生在自己的模塊，而發生在別的模塊了。
現在的軟件都是分層的，數據在不同層進行傳輸，操作數據，這樣每層可能都會帶來問題，當自己身處於某個層的時候，對於接收到的數據，應該和自己的底層做好明確的定義，數據格式應該是什麼，什麼樣的數據是正確的，什麼樣式錯誤，這樣就能把責任劃清。數據格式正確，問題發生在自己的層，那應該就是自己的代碼邏輯的問題，如果數據格式錯誤，就應該傳輸數據層處理，爲什麼出入錯誤的數據。最討厭的是，責任不明確，問題誰處理都可以，這樣會造成討論時間的浪費和相互扯皮，只是浪費時間和浪費情感。
從軟件各種書籍看，問題越提早發現越好，越容易處理，但是有時候我們不能要求別人，只能自己管好自己，對傳入的數據進行校驗，保證自己的代碼邏輯處理的是正確數據，如果是錯誤數據就馬上停止運行，輸出錯誤信息，可能需要自己添加一個數據校驗層。
總結起來就是，層與層之間一定要做好定義，按照大家討論好的標準來做，做好責任劃分。如果責任一直沒有劃分好，我們儘可能地推動這件事件，如果推動不了，那就儘可能的讓自己的代碼邏輯足夠的健壯和容易debug。另外如果有時間，可以適當瞭解上下層的處理邏輯，這樣溝通起來更方便，更順暢。