有軟體就有
bug，這意味著軟體研發不僅僅是新功能開發，更要拿出相當一部分精力去修改
bug。但基本很多軟體開發者並不喜歡修改
bug，對這項工作的厭惡程度並不下於寫文件。究其原因有以下幾點：一是修改
bug並不會帶來像開發新功能那麼大的成就感，甚至修改
bug意味著承認自己開發的軟體中存在缺陷，這毫無疑問會給人一種沮喪感；二是修改別人開發模組的
bug意味著吃別人的**，等於自己要去讀懂別人寫的**，理解別人的思路，彌補別人犯下的錯誤，很多時候意味著要付出更多的辛勞。
但是bug
又是不能不改的。需要認識到的是修改
bug並不是低技術含量的工作。相反它是一項相當有技術含量的工作。隨便將乙個
bug扔給乙個新人來修改是一件不負責任的事情。首先需要有豐富開發經驗的開發者劃分
bug的難易程度，制定
bug修改技術方案，然後安排新手去修改才是比較可行的路線。
bug修改不適宜長時間連續進行，應在開發新功能和修改
bug交替進行，比如一周五天時間，有三天開發新功能，有兩天修改
bug。長時間連續修改
bug容易造成對
bug修改的厭倦，就好像經常吃速食麵的人到最後是看見速食麵就想吐。還有對於一些設計方面有嚴重缺陷的**適宜採用**重構的辦法來修改，這也是償還之前的技術債，否則到最後是積重難返，**變得無法維護。
Android中關於修復bug的思考
這兩天在做專案的時候，走了很多的彎路，特此做乙個總結吧。在android裡面adapter和listener是我們用的最多的吧。這兩天一直因為乙個資料錯亂的問題，找了很久才找出問題所在。感覺，乙個bug，往往改問題只需要 一 兩分鐘，找問題可能需要好幾個小時，甚至是1天。所以我在想，排錯的時候，應該...
BUG修改記錄之關於測試
jmesa的columnsort的定製，在setcolumnsort自己定製的columnsort之後，沖掉了預設的sort，沒有測試一下其他的功能，只測試解決的問題的功能，導致出現bug，失敗失敗。ps 這裡面體現到專案自動化的重要性了，按照理想情況，如果每乙個點都寫上單元測試，在修改完乙個點之後...
BUG，帶給我的思考
今天開啟evernote時，翻到了四年前在anjuke時做的一些bug分析總結。現在回過頭看看也是有些價值所在，挑選出部分bug分享，希望能有所啟發。一 nsarraym objectatindex index 20 beyond bounds 0 19 nsarraym objectatindex...