眾所周知：基本上所有的軟件項目到后期必不可少的是fix bug，一個軟件在交付客戶后或交給測試人員測試時都存在一些程序員意想不到的問題。現在有一些成熟的bug跟蹤系統，譬如：bugzero，bugzilla， redmine等等。
解bug是很頭痛的問題，一般是以下原因引起的：
（1）設計上的缺陷；
（2）寫代碼時考慮不周全；
（3）測試人員無中生有；
（4）所依賴的插件，框架本身的缺陷。
第一種情況：最棘手，需要修改程序架構，費時又費力，但是不改又不行總不能要客戶該需求，按照你的程序來吧。沒辦法，改吧。
第二種情況：還好，看看是那里出來問題，改改代碼就可以了，但是改完后需要確認一下會不會對其他模塊或功能造成影響。一般如果影響很大的話，那就是模塊之間的耦合度太高，不是高質量代碼，會越改越亂。
第三種情況：
a、撰寫需求文檔時，對軟件需求設計模糊不清，讓人產生歧義。譬如在編寫需求文檔時考慮不周留下讓人發揮想象的空間，或前后矛盾。
b、測試人員或者軟件開發人員對沒有真正理解需求，譬如文化差異導致理解不一致。
c、測試跟你有仇。呵呵。。
第四種情況：
軟件越是開發到最后，bug的難度越大。因為這時你對代碼一丁點的改動就有可能引發新的bug，這里不管你的設計的如何如何好，模塊與模塊之間的耦合度如 何如何低，都不可避免。深層次的問題也慢慢暴露出來，那就是你項目依賴的東西，譬如第三方的插件，框架本身的缺陷或者由于對他的不了解造成的誤用。這些 bug才是最頭疼的。雞肋雞肋啊，棄之可惜，用之可悲。
不過，作為一個執著的程序員或軟件工作人員，基本的職業道德還是要有的，不能有了難解決的bug就退縮。實際上雖然解決bug學不到新東西，但是還是有好處的：
（1）可以讓你更加深入的了解你自己，了解自己一直以來被忽略的“缺陷”。
（2）考驗你的耐心和忍耐度，極限。
（3）增加程序員之間的溝通，促進感情交流。
這個要說一下，遇到自己解決不來的bug，可以請能解決的人幫忙看看，有了高人指點也能讓自己多學點東西，學的不是這個bug這么解決的，而是人家遇到問題的思考方法為什么比你寬廣，找到原因后，你就可以和他一樣無所不能了。哈哈。。。
（4）可以在閑暇之余給自己沖沖電。
項目初期和中期都是比較忙的，任務滿滿的，基本沒有閑暇時間。后期就不一樣了，bug少的人就可以多一點自己的時間。呵呵，就看你這么利用了。
以上是我對軟件項目后期Fix bug的意義的思考，希望對廣大軟件工作者有所啟發。也在此勉勵那些不在bug中沉默就在bug中爆發的人，好自為之吧。