代碼風險預防上的一些看法

java.lang.IllegalStateException: The content of the adapter has changed but ListView did not receive a notification. Make sure the content of your adapter is not modified from a background thread, but only from the UI thread. [in ListView(-1, class android.widget.ListView)
with Adapter(class android.widget.HeaderViewListAdapter)]
at android.widget.ListView.layoutChildren(ListView.java:1492)
at android.widget.AbsListView.onTouchModeChanged(AbsListView.java:1960)
at android.view.ViewTreeObserver.dispatchOnTouchModeChanged(ViewTreeObserver.java:591)
at android.view.ViewRoot.ensureTouchModeLocally(ViewRoot.java:2087)
at android.view.ViewRoot.performTraversals(ViewRoot.java:1023)
at android.view.ViewRoot.handleMessage(ViewRoot.java:1793)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:4627)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
at dalvik.system.NativeStart.main(Native Method)

所有的話都從上面這個異常說起。

一、bug位置追蹤。
這個異常比較頭疼的是從調用鏈上面判斷不出問題出在哪兒，而從UI樹裡面捕捉異常又不可行。只能看哪裡使用了這樣的UI樹，然後判斷出什麼地方出問題。這個問題已經不只是一個簡單的技術問題了，因為不能定位意味著不能確定誰的責任。無法界定責任人，那執行力就無從談起。這就引出了一個我今天想哰哰的話題，代碼的責任界定。

二、代碼的責任界定。

這個事情簡單來說可以從兩個方面來看。一個是開發前，項目的技術架構要保證人員之間的任務劃分高內聚、低耦合。另外一個是出了問題時，比如代碼崩潰之後，可以很容易界定屬於誰的問題。今天重點說第二個。
要在出現問題以後迅速界定問題責任人，可以有這麼幾個方法：
1、最普遍的方法就是看異常鏈。這個開發時可以這麼幹。但發出去的混淆包監測到的異常就不能這麼幹了。
2、如果要對付代碼混淆後出現的異常，就需要給每個類打上Tag，通過在反編譯後的檔案中尋找Tag來把問題範圍迅速的定位到類級，從而迅速界定責任人。接下來，再進一步通過方法的參數個數、類型來界定出現問題的具體方法。
3、針對上面這種極品的異常鏈，只能特殊問題特殊處理了。看一下哪個Activity使用了這種UI樹。把這個Activity中使用到ListView的Footer或Headder的地方檢查一下是不是沒有把修改Adapter資料的操作放線上程的最前面。
不知道大家注意到沒有，從第3點可以看出，項目中總有些地方是只有具備豐富經驗的人才能少出問題，或者出問題後迅速解決問題。這就引出了我想出的另一個話題了，怎麼通過程式之外的方法保證程式穩定可靠。

三、代碼Review

執行代碼Review時需要注意這麼幾個操作流程：
1、公布正常化的代碼標準，以及容易出問題的地方需要注意的事項（比如引起上面這個異常的原因就是其中一點兒）。
2、1個進階工程師帶1～2個初級工程師。進階工程師對初級工程師的代碼負責周期性Review。
3、周期性的在團隊內部對整個項目中的模組進行集體代碼Review。一個是監督大家執行代碼標準，另外一個就是補代碼標準裡面沒有細化到的地方。

代碼的風險控制是門很深的學問，大家多多拍磚。