如何去安全的在別人寫的現有代碼基礎上修改或者添加功能， 儘可能少的引入bug？
修改或添加代碼的效果，都必須基於對現有代碼的理解程度，理解得到位，改起來就順利一些， 而如果理解不到位，就容易產生疏漏。
當然對於一個比較大的系統，比如android， 想看懂其中哪一個模塊都是不容易的。很難一下子就保證完全理解正確， 那是不是要等確定完全理解正確才下手呢？
從《代碼大全》中認爲，很多問題都是“險惡”的，你必須首先把這個問題“解決”一遍，以便明確地定義它，然後再次解決該問題，從而形成一個可行的方案。希望把代碼完全理解，然後設計、修改，最後一次性就解決問題那是不現實的。
首先，仔細閱讀現有代碼，在確認比較理解之後，可以開始着手解決問題，提出修改方案，與相關同事討論，討論清楚後再下手改代碼，同時每次在修改時注意打上標籤，方便以後回溯。完成修改後，仔細檢查，在腦子裏模擬運行幾遍，把低級錯誤排除掉。然後開始驗證。
這裏要說的是，在解決問題之前準備工作是很重要的，一個錯誤的方向往往會導致一個錯誤的結果，對效率的影響還是很大的。多討論、多思考，在設計時就應該嚴謹一些。
在驗證時，不要僅僅滿足於功能看起來完成了，在關鍵點打上日誌或者藉助一些調試工具（gdb?），仔細觀察運行狀態，不放過任何一個看起來無意的異常， 因爲它們極有可能在某個臨界點崩潰。儘可能的讓它由表及裏都正確。
事實上，很多時候事情並沒有想象中的順利，在運行調試時，你會發現對代碼邏輯原本就有點模糊的理解現在又變成了一團漿糊，調試變成了不斷的瞎猜亂試，然後寄期望它突然恢復正常。這時要小心了，繼續下去只會產生一個漏洞百出的破爛。 不妨跳出來，再看一看代碼，重新理一理思路，等理順時，對問題的理解又上升了一個臺階。ok，接下來再重新從整體上修改設計，實現，驗證。。。這樣一個個循環下來，你對問題的理解越來越全面，添加或修改的代碼也能更自然的融入原來的體系，安全性也就大大提高了。
解決問題分爲幾輪：
1. 在現有領域知識背景下，儘可能把問題思考清楚， 然後解決一遍問題。 容許犯錯， 漸進式解決問題。
2. 第一步由於知識受限， 你的思考會存在盲點， 現在解決過一遍後， 你會更清楚問題， 在重新從整體上思考一遍問題， 思考清楚，條理化， 再解決一遍問題。
這次的任務是添加彩信手動播放小功能，工作量不大， 收穫卻也不小，裏面有一些經驗教訓很值得一說。最想說的第一句話是： 靠肉眼看，憑邏輯推是不夠的！
調試時有一個問題一直在糾纏我。彩信播放時是按頁播放的，每次快進/快退時，需要先停止當前頁的播放和媒體元素信息(如播放的音頻文件名和圖標)的顯示，重新加載新位置的彩信頁，並更新新頁媒體元素（如音頻）顯示信息，然後繼續播放。bug的現象就是在播放含音頻的彩信時，拖動播放進度條進行快進/快退，元素信息停止顯示，然後就沒聲音了。 要命是它還不是每次都沒有聲音， 時有時無。 我的調試方法就是靠肉眼看，憑邏輯推：仔細看代碼， 推敲每一處的邏輯， 在可疑的地方修改， 編譯後下載到手機上驗證看現象是否消失。
可是呢，調試的過程異常不順利，改代碼-重新編譯-下載，效率低下我也就忍了，關鍵是怎麼改現象都還是“濤聲依舊”，最後能檢查的都檢查了，能改的都改了，還是一次次失望。。。實在猜不出問題所在，於是下了個結論，系統本身的bug，藏的很深，搞不定。
第二天請來高手幫忙，他根據現象，猜測可能是在哪裏調用了停止播放的函數，導致重新加載頁不成功。我立即說，不可能，我仔細檢查代碼了，不可能調到那裏去。他依然堅持自己的觀點，然後在關鍵點打上log，並打印相應變量的值，最後告訴我，機器是不會騙人的，調了就是調了，沒調就是沒調，跑的時候看一下日誌就知道了。 由於他也很忙，加上那些日誌代碼後，就走開了。
我坐在那裏，心想怎麼可能，邏輯上都推不過去。半信半疑的下載到手機裏， 然後一行一行的看日誌，暈，還真的調了！根據其他的日誌信息，我很快找到了問題所在，一切也就迎刃而解了。
通過這個印象深刻的經驗，我得到了以下的關於調試的體會：
1. 在修改bug時，不要急於把現象去掉， 那樣可能暫時現象不重現了，但卻沒有真正解決bug，還會隱藏的更深，遲早還會爆發的。治標更要治本，到處瞎試是沒用而且危險的。（寫給自己： 通過sleep減少了現象重現機率，但還是沒有真正解決問題）
2. 通過bug現象，可以初步猜測問題所在，然後在可疑點處打log，運行中仔細驗證你的想法。跟進去看看具體發生了什麼，你才能真正成功調試。--大膽假設，仔細驗證。
3. （寫給自己的）還記得joel 寫的 leak of abstraction嗎？