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 * 是一个很欠好的编程风俗，除非用到全表移植等特殊应用，能不消只管不消。

新誊写代码必须有类分析【从前的就算了，只有如许各人才气多思索一下我们的类是否公道、是否是面向对象的筹划】