关于Bug太多问题的思考

问题：代码Bug太多, 每次大家功能自测的时候，都能通过。 但提交QA后，总能发现bug, 即使某一轮测试提的bug全被修复，下一轮又会产生新的bug，总之不管怎样，Bug就是“野火烧不尽，春风吹又生”；

这个问题，我敢保证绝大多数开发者都经历过，也是让开发者、开发负责人、项目经理都感到头大的问题。

首先，我想说明的是，完全消除Bug是不可能的，我们不该也不能抱这这种想法、心态。 如果说哪天代码没有Bug了，那一定不是人在写代码，就算机器也代码，也不一定没有bug吧。

我想原因有以下几点：

1. 项目架构的不太行：

   如果框架本身不好，那bug绝对少不了。 好的项目框架，可以减少bug；更好的项目框架，甚至让开发者连犯某些错误的机会都没有； 而不好的项目框架，还会帮忙制造bug。

2. 项目进度不合理：

   2.1 一个功能本来需要10天，公司为抢占先机和节约成本，领导要求8天就要完成。 负责人也出于某些原因或目的，要求开发者7天就要完成。

   2.2 然而有些开发者觉得自己只要6天就能开发好（这个开发者的能力有关）。 为何觉得6天就能完成呢：
   <1>. 很多开发者多对任务有个错误的认识，认为就是写代码，实现功能而已。 而实际上还有单元测试、集成测试、接口文档、效率调优、依赖方改动适配，多场景自测等一堆的东西，都需要花时间去完成；
   <2>. 大部分开发者本身会过度的相信自己写的代码，不会认为自己的代码很脆弱；这种自信会让开发者不会也不愿意花太多时间去测试、去回归。

   2.3 再然后，领导说既然6天能完成，那加加班，按先紧后松原则，5天就完成吧。 由此，10天的任务，最后可能5天就完成了。

   – 代价就是后期会反复出现意想不到的Bug，看似意外却都在情里之中。 本来的先紧后松应该是： 紧紧紧松松松松，后来变成了：紧紧紧紧紧松紧紧紧松。 并且修复这些问题的代价，也远不止一开始省下的5天。

3. 开发者本身的能力和态度问题：

   3.1 每个开发者都是从入门到精通，该踩的坑一个也别想少，所以写Bug是必然的。
   3.2 写代码这个事儿，本身是需要一些个工匠精神在里面的。 然而社会崇尚的是“效率至上”，这和“工匠精神”本身是有冲突的。 对部分开发者，会认为既有时间，为何不去学点新知识来作为以后跳槽和加薪的筹码，而要花在打磨代码上面。
   3.3 就像上面提到的，开发者普遍的有些过度自信，亦使其不会过多的自测。

4. 制度或管理者本身的能力和态度问题：

   普通开发者权力有限，即使发现问题，并且难得的有去解决问题的决心，可最后只能解决好自己负责的模块。 因为对整个项目来说，他说了不算，是制度说了算，是领导说了算。 这个关于能力，关乎责任，关于权力，关乎面子，不必细说。