Bug及优化

作为一个软件公司，bug大家都不会陌生，这个话题我以这首古老英格兰民谣开始： 失了一颗铁钉，丢了一只马蹄铁；丢了一只马蹄铁，折了一匹战马；折了一匹战马，损失一位将军；损失一位将军，输了一场战争；输了一场战争，亡了一个帝国。铁钉和帝国，表面看毫无关联关系，但世界就是这么奇妙，通过一连串的作用两者发生了紧密的联系。下面我就bug几个层面和大家做一个探讨：

bug的本质是什么？

1、bug是不可避免的，除非不写代码。要经常问自己这次的bug是不是由于自身没有良好的工作习惯引起的？

2、不要有解决修复bug感觉自己水平低、没面子的负担，不养成好习惯、技术水平不提高，最终影响最大的还是自己。【要通过不停的修复bug，多思考如何去避免bug，自己的能力才能不断提升】。

3、在工作过程中，一定要多看看后台，系统是否是按设计的逻辑运行的；把所有数据操作流向思考一遍，是否有问题；从页面的左上--》右下，涉及的功能尽量都要覆盖测试一下【不要为了赶工期而忽略这些好的习惯，因为有些地方出问题修正就好了，而有些地方出问题市场、客户连修正的机会都不会给你的】，要从根源上尽量杜绝bug。

4、较简单顺手可以修改的bug要尽量快速修改--a、时间长容易忘；b、尽量给客户、给项目组一个快速响应的印象，这样遇到比较复杂的稍微响应慢些就都能理解了。

5、出了bug不可怕不改进就彻底完了，失去了坚持改进我们就会丧失速度与热情。

6、最好的系统，就是下一个系统。当一个项目结束时，总感觉一些方面不尽如人意，甚至是垃圾，到下一个项目又是如此，如何我们能把自己负责的每个项目或每个功能中失败的地方的50%不出现在下一个中，相信不久以后你必定有所成就。

如何对待bug？问题出来后，除了全力修复bug、测试外，还要静下心来思考一下，开发：为什么会出这些bug、bug的根源是什么、以后有没有可能避免；测试：为什么会遗漏这些bug、下次应该如何测试；实施：这些bug是否与学校的环境有关，是否是数据的问题。

bug修复的优先顺序？

1、已经上线运行使用频繁功能的bug； 2、影响较大的bug； 3、较简单的bug ；4、较简单的任务（客户能快速见成效且工作量在0.5人天以内）； 5、较重要的任务； 6、较复杂的bug or 正常的任务 【任务级别有疑问时要及时提出来讨论、协商】。

我感觉我们要以行业专家的自信去做设计，首先要说服我们自己接受自己的设计。当然如果用户有好的想法我们会去修正我们的设计，并重新说服自己去接受自己的设计。针对各个群里遇到的产品、工作的问题，我们要：当我们遇到一个问题时，尽快解决他是第一位的，但事后的反思也很重要。很多问题是不可避免的，本身也不可怕，可怕的是没有反思怎么避免下次不出问题的劲头，造成同样问题或同类型的问题反复的出现，这就很可怕了：因为随着时间推移，你做的每一样事情都可能没有把握，都可能出各种各样的问题，严重影响团队协作的同时拉低了自身的水平。遇到问题，如果是别人的，要思考：1、我自己会不会有同样的问题；2、该问题我遇到如何解决；3、该问题有没有可能避免。如果是自己的，更要思考：1、问题产生的根源是什么；2、该问题下次通过什么方法可以避免；3、如果无法彻底避免有没有方法降低问题出现的概率。

除了bug外，代码的优化也尤为重要，只有不断进行代码的优化，bug出现的几率才会控制在很低的范围内；优化代码不同于bug修改，bug是已经发现了问题，优化是问题还没有暴露，所以优化代码要注意尽量做到向下兼容，这样才能不断增加优化代码的信心【否则则会不断陷入聋子治成哑巴的困局，再也不敢去优化代码】。

------------------------------------------------------

对于采用selectsql取出结果集再length求数量：这个是不是由于order by不直接用selectcount，如果是建议把order by替换掉再求count。selectcount还是比selectsql的效率高，节省了网络传输量，算法也更优化。

select * 是一个很不好的编程习惯，除非用到全表移植等特殊应用，能不用尽量不用。

新书写代码必须有类说明【以前的就算了，只有这样大家才能多思考一下我们的类是否合理、是否是面向对象的设计】