程序員不是有一幅這樣的對聯嗎
上聯：一個項目兩部電腦三餐盒飯只為四千工資搞得五臟俱損六神無主仍然七點起床八點開會處理九個漏洞十分辛苦；
下聯：十年編碼九年加班八面無光忙的七竅生煙到頭六親不認五體投地依舊四肢酸軟三更加班只為二個臭錢一生孤苦；
橫批：苦逼程序員。
其實，程序員職業生涯總結起來就這三件事情Ⅰ理解需求 Ⅱ編碼 Ⅲ改bug。
可見，bug是程序員的天敵。bug對於我們自己名譽和產品自身質量影響是不言而喻的。哪么，怎么能夠降低bug了。
卡耐基說過，人性的弱點要克服。程序員必須克服一些自身的致命缺點才能夠從根本上解決這個問題。這個問題是什么了？程序員對自己的代碼都非常寬容，認為那是正確的沒有問題。這種想法也是人之常情，畢竟程序是程序員經過縝密的思考和設計之后才寫出來，不會將錯誤的東西寫到代碼中去。但是人非聖賢孰能無過。實際上程序員在程序上是挑剔別人，寬容自己。這往往是最致命的。程序員必須對自己的代碼有一種“吹毛求疵”的態度，首先，大膽假設自己的代碼是錯誤的，需要證明自己的程序是正確的。這樣就需要做以下一系列的工作：仔細的設計(這個時候畫點時間是值得的，必須保證我們對自己的程序有清晰的輪廓后才能開始動手寫)、編寫代碼時、單元測試(單元測試的重要性就不在贅婿了)、功能測試。
仔細的設計：更多人願意稱之為詳細設計。這個的仔細是說在程序員編寫代碼之前，其必須對代碼的整個結構以及邏輯結構有明確的清晰的了解，只有這個時候才可以去寫代碼。這里沒有談到文檔，但我說到了一定要清晰的思路，但清晰的思路不是每個人都可以在腦袋中直接形成的，很多人都是普通人，沒有辦法在腦袋瓜中把所有問題都想清楚，那么就記下來，特別對於復雜的邏輯。
編寫代碼：對於沒有把握的代碼，例如：新設計的算法，最好保證其正確性。可以單獨將這部分測試，這就是我們所說的單元測試，我們公司要求每個新方法必須進行詳細設計。這可以讓代碼模塊化的同時又保證了代碼的正確性。一句話：少量的代碼保證質量還是比較簡單的。
單元測試：單元測試的重要性不在贅敘了，現在也有許多工具可以幫助程序員並減少工作量。android中android instrumention是不錯的選擇。
功能測試：程序員保證自己代碼質量的最后一關;為了做這樣的工作我們可能必須寫一些代碼來測試，甚至是測試工作。使用大量的 CASE 來測試，以及錯誤的 CASE 。這里和測試人員的測試不同之處在於：仍然讓程序員的注意力放在其自己的代碼范圍內，減小了排錯的難度。
如果你通過了以上的步驟都找不出你程序中有任何問題的話，那么我想你的程序應該足夠健壯了。其實還有一點必須說明的就是：代碼 REVIEW 。
前面說道了程序員對待別人代碼的態度是挑剔和學習的態度，所以讓其他程序員來 REVIEW 你的代碼也是檢查程序有沒有邏輯錯誤的很好的辦法。團隊中應該交叉 REVIEW 代碼，這是實踐的經驗。
作為一個好的程序員必須有以上的習慣，以及對待自己代碼象孩子一樣，我們要愛惜我們的代碼，同時也要讓代碼走正確的路。
以上的方法，是防患於必然的方法。哪么怎么解決bug了。
程序員八榮八恥說道：
以日志調試為榮，以單步調試為恥。
控件調試bug首先打印日志，最后迫不得已再單步調試了。
這就是我的bug全攻略，希望對大家有所幫助。