对用户来说，体验不好，出现缺陷，没有什么产品缺陷与开发缺陷之分，就是产品体验差，垃圾。当出现缺陷的时候，往往我们先馅于“在这不是bug是需求，是需求还是bug纠缠中。这种毫无建设性的争辩，没多大意义。我们是一个团队，无论是哪个岗位都应该有责任主动或协助解决这些问题，而不是只守着自己的一亩三分地。只有大家有共同的目标——把产品做得更好！才会对每一个人的成长有所帮助。

刚刚在头条看了一个关于“程序员工作汇 ”的视频，工程师向项目项目汇 工作时说：

“上周五呢，我们项目还剩下3个bug，经过一周的奋斗呢，我们现在只剩下73个bug，所以说，本周工作进度是，我们解决了-70个bug,每天解决-10个。虽然我们bug数量增加，但是我们增加bug的趋势是下降的，我做了一套模型预测了我们项目解决所有bug的时间是上个礼拜”。

产生了一系列的思考：

1. 工程师的内心是如何看待Bugp>

2. 大量的缺陷，受影响有哪些方面，影响有多大p>

一、缺陷所带来损失和负面影响。

1. 缺陷过多是软件开发中最大的浪费。

2.重复不断修复缺陷工作，会让员工产生焦虑感，减少工作激情。

缺陷所造成的影响，取决于它被发现的时间和它的大小，越早找到缺陷越好，在写需求的阶段就被测试人员发觉，是最好不过。

缺陷是如何产生的呢

首先缺陷可分为两类：产品缺陷和开发缺陷。前者更多是因为产品需求没有考虑到，或者下意识认为这是基本的功能，开发人员肯定知道。下面我举个亲身经历的一个例子。当时我作为项目经理，体验了其中一个在项目收尾的App,发现“视频推荐”栏的视频无法跳转（如下图），于是发生了如下一段对话。

我问开发同事： 这个点击后没有反应，不是有问题p>

开发人员： 需求上没有写要跳转啊~

于是，我找了测试同事，问：这个明显是一个bug，怎么没有测出来p>

我被测试同事的回答惊呆了：“这个确实是需求上没有说明。”

【这里我稍微解释下，公司是做外包的，我刚入职不久，之前一直没有项目管理人员，项目流程很混乱，需求文档不过是简单的Excel功能类别，同时公司的外包思维非常严重，更关注怎么快点交付收款，而不是产品质量】

软件开发时，bug总是自动在过程中被隐含进来。通常产生原因有下：

1. 一知半解写程序。这是制造bug的最大元凶，这种bug最难以检测出来。

2. 逻辑思维被打断。开发过程中被其他事情干扰，注意力不集中，部分逻辑没有想到。

3. 程序写复杂了。由于软件的复杂性，是我们把程序写复杂了，例如程序写得很长，隔段时间自己还大骂这是谁写的。

4. 工作技能不足。例如出现空指针，数组越界，把A==B写成A=B等等。

对于第4点，有些开发工程师会较劲，这跟技术有什么关系，只不过是粗心而已。举个例子，高中时候试卷发下来之后，总有不少同学这样辩解安慰自己：“哎呀，都怪我太粗心了，这道题应该要做对的”…高考也一样，以成败论英雄。粗心也可以说是一种能力缺陷。

我们是如何看待开发bug的呢h1>

“有bug是正常的，开发时间太赶了”

“谁叫产品经理整天把需求老变来变去”

“需求设计如此，你问产品经理吧”

在开发工作时制造一大堆bug，然后再费尽心思把它解决掉。有趣的是，解决这些bug之后还能获得相当的充实感！反倒是很少有人回过头来检讨这些bug实际上都是自己所造成的。

很多程序员会以“开发工作太紧张”为理由，而忽略测试工作，花在找Bug、解决bug的时间越来越多，实际的产能大大降低，代码产能降低了，因此时间更紧张了，压力更大。

专注于质量

提高初始质量，会对高缺陷率的团队的生产力和交付速率产生巨大的影响。获得2~4倍的交付速率提升是很有可能的。如果团队真的很糟糕，那么通过“专注于质量”的做法，甚至都可能获得10倍的交付速率提升。

提高代码质量的方法有很多，下面罗列非常有效的一些方法：

1、测试先行/测试驱动开发

先举个例子，两个不同的工匠是如何工作的。

工匠一：先拉上一根水平线，砌每一块砖时，都与这根水平线进行比较，使得每一块砖都保持水平。

工匠二：先将一排砖都砌完，然后再拉上一根水平线，看看哪些砖有问题，对有问题的砖进行适当的调整。

你会选择哪种工作方式呢定会骂工匠二笨吧！这样多浪费时间！这时你想想，你平时在编写程序的时候又是怎么做的呢p>

不要试图在结束的时候“测试”质量；相反，我们在整个开发过程中构建产品质量和持续地确保质量。

2、代码检查

卡珀斯·琼斯（Capers Jones）分析了超过12,000个软件开发项目，其中使用正式代码审查的项目，发现潜在缺陷率约在60-65%之间，若是非正式的代码审查，发现潜在缺陷率不到50%。大部份的测试，发现的潜在缺陷率会在30%左右。

无论是同行评审、代码走查，或者是完整的费根式检查，进行代码检查都是很有效的。代码检查能够帮助改善外部的代码质量和内部代码质量。代码检查最好经常做，并且以小批量进行为好。我建议团队成员每天至少花30分钟进行代码检查。关于如何代码检查方面的知识 上有很多，就不再这里详细展开了。

3、协作式的分析和设计

团队一起分析问题和设计解决方案，产出的质量更高。我建议团队成员召开协作式的分析与设计建模会议。设计建模应该小批量的方式每天进行。

4、使用现代开发工具

许多现代开发工具都包括静态代码分析和动态代码分析的功能。例如，Findbug插件。对每个项目，应该把代码分析的开关打开，不断进行代码优化。这些分析工具，可以防止程序员犯低级错误，如安全漏洞这类众所周知的问题。

5、频繁交付

有相关数据统计分析表明，迭代时间和质量存在相关性，迭代时间长，则质量会下降，迭代时间越长，质量越会显著下降。事实上，平均迭代时间增加约6.5倍，便会导致初始缺陷超过30倍的攀升。

缩短迭代长度，将对初始质量产生重大影响。为期两周的迭代比4周的迭代好是很有道理的。较短的迭代会产出更高的质量。为什么以小批量的方式进行编码能够提高产品质量其实很容易理解。在知识工作中，随着进行中工作项数量的增加，问题的复杂性也会呈指数级增长。

总之，减少一个迭代中的工作项，固定时间的迭代，能够提高产品质量，并促进更为频繁的发布。更为频繁地发布更高的质量的代码，能增进与外部团队之间的信任。

频繁发布能够建立起信任。举个例子：

一个女生与某个男生第一次约会后的感觉。假设她的那次约会很愉快，但是之后两个星期他都没有给她打电话；而某一天，他突然满脸歉意地拿着一束鲜花出现在她家门口。

另外一种类型的男生，会在当晚约会回家的路上给她发短信说，“今晚和你在一起的时光太美妙了，我真的很想能够再次见到你。明天给你打电话可以吗”，并且第二天真的打了电话过来。

把这位男生和另外一种类型的男生进行比较。猜猜女生更喜欢哪一位p>

微小往往不费分文，较之那些大而昂贵（甚至夸张）但偶尔发生的表现而言，能够建立起更多的信任。

6、频繁单元测试

1）不要所有开发完，才进行单元测试。频繁运行验证功能的可用性。

2）慢工出细活，别急于下手写代码，先脑中捋一遍业务逻辑，在脑里写一遍。减少写了一半程序发现这种方式是存在问题的，或者有更好的方式，于是删掉代码重新来一次。

一个小技巧：做完几个简单的功能，就启动程序或刷新页面，看看有没有达到我期望的效果，这也是获取成就感的过程之一。

其他

代码共同所有权

项目组的每个开发成员都有更改代码的权利，所有人对于全部代码负责。代码全体拥有并不意味着开发人员可以相互推诿责任，而是强调所有的人都要负责。如果一个开发人员的代码有错误，另外一个开发人员也可以进行BUG修复。

超负荷工作

开发人员即使能够工作更长的时间，他们也不该这样做，因为这样做会使他们更容易厌倦编程工作，从而产生一些影响他们效能的其他问题。如果不懂得休息，那么就无法将自己的节奏调整到最佳状态，那么就会带来很大的负面影响。而且在精神上不集中的状态下，开发质量也得不到保证。