众所周知：基本上所有的软件项目到后期必不可少的是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中爆发的人，好自为之吧。