概述

最近参与了几个需求开发，BUG很少，有些需求没BUG，有些才一个BUG，搞的测试人员还发牢骚说，

大佬，你负责的项目，bug都少的可怜，叫俺怎么活？

哈哈，其实测试人员要感谢我才对，因为开发人员的代码质量高了，会极大的提升测试人员测试的速度，因为测试过程中非常顺畅，没啥阻碍的东西。设想一下，如果提测后，代码BUG满天飞，测试人员不断的提BUG单，开发人员不断的修复，一不小心还可能修复出其他BUG来呢，中间还穿插各种各样不必要的讨论，这些都严重影响了测试进度，当然也严重影响了测试人员和开发人员的心情。因此：

最好是在开发阶段就认真起来，把代码写好，以求后续流程的顺畅性。

那么如何做到写代码的时候，尽量避免BUG呢？趁这个机会也跟大家分享一下我的做法。

尽量避免bug的手法

与产品经理和经验丰富的测试人员多沟通

需求阶段

产品经理正式开需求会议之前，一般都会先把需求文档发出来，这个时候，开发人员一定要认真的看并仔细分析，每个细节都要多想想，有疑问的地方及时跟产品经理沟通。另外，看需求的时候，最好跟熟悉业务的测试人员多多沟通，测试人员是对以往需求最清楚的人，能看到其他人看不到的细节。像我自己就经常从测试人员那里，听到了一些要命的而我却忽略掉的需求细节。

代码设计阶段

我一般想好方案后，第一时间就会去找技术老大和熟悉业务的测试人员。能做到技术老大，他的思路一般都是比较广的，多听听他的意见是没错的。另外，也要去找测试人员，有些开发可能认为，技术方案怎么会去找测试人员商量呢？请不要忘记，部分测试人员是对整个公司的大部分应用和需求和业务都了如指掌的人，能清楚的知道系统与系统之间如何交互，整个链路是怎么走的，整个上下文又是怎么样的。当开发人员的设计方案出来后，表面上看起来，完美无瑕，其实可能存在影响上下游系统的隐患。而多与熟悉业务的测试人员沟通，则可以尽早把这些问题暴露出来，减少影响和损失。

代码开发阶段

必须写单元测试

单元测试的重要性，无论怎么强调都不为过。它是用于测试自己写的代码是否符合预期的极好的手段。尤其是在创业公司，需求都非常多，经常需要改代码，如果没有一套完整的单元测试来回归验证代码，分分钟由于新写了代码而破坏了原有的代码功能。单元测试可以让开发人员放心大胆的改代码，无需担心影响之前的功能。

但是单元测试一定要认真负责的写，尽量覆盖主流程业务。那种随便写写，随便验证的单元测试，不写也罢，没啥意义，还浪费时间。写单元测试经常犯的另外一个错误是，由于急着改bug，忘记同时改单元测试了，导致之前跑过的单元测试，后面又跑不过了，这个是绝对不允许的，单元测试也必须持续维护的。

另外有一个点就是，开发人员提测后，理论上就可以接另外一个开发任务了，如果开发阶段BUG太多的话，则会影响下一个开发任务的进度。这个是开发经理不愿意看到的。

不断的重复的看自己的代码

代码提测前，要多看几次，有时候能看出一些隐藏的代码BUG的，有时候也会觉得，昨天写的代码，真垃圾，还是有蛮多代码要优化的。

在看代码的时候，最好顺便做到下面几点：

代码收拢性要强，不要存在那种类似的代码满天飞，能封装起来的就封装；
业务代码一定要有必要的准确的注释，千万别信那套方法名命名好了就能解释清楚的鬼话；
变量名要起好；
代码抽象层次要一致，不要跳跃，例如，你的业务方法，操作其他模块业务表的时候，都是调用Service类的，就不要突然冒出个直接使用xxxxxMapper去操作数据库表了；
流程性比较强，最好用 //1、 //2、 //3、标注一下，这样会更加清晰。

必须做开发联调

当你的业务接口开发完成后，一定要做开发者之间的联调。联调是端对端的，就算其中一方做的再好，没有联调，还是会出问题。

开发联调通过后，建议叫产品过来提前验收

一般来说，功能测试通过后，上线前，会让产品先验收一下。但是我则喜欢开发联调完后，就先拉上产品经理，先大概验收一下。不要小看这一步，经常能提早发现一些问题的。

开发人员列出改动了哪些已有接口

列出改动细节有个好处：

让测试人员更加有针对性的做回归测试。虽说每次项目上线前，测试人员会做回归测试，但是很难做到全面回归，而没有回归到的场景，到线上可能就会造成bug。如果开发人员能列出改动点，则测试人员可以重点且认真的回归。

已有接口已经是在线上验证过的接口，如果改动了，是一定要做兼容性测试的，既要保证新功能可用，也要保证不影响旧功能。

尽最大努力,保证开发提测不delay

对于那种上线日期已经定了，一般会采用倒排的方式，推导出，开发哪个时间点提测，测试人员什么时候介入测试，测试多少天等，都会安排好。如果开发提测delay了，留给测试人员的测试时间就缩短了，会给测试人员造成很大的压力，压力一大，则更容易出错，直接影响测试质量，也就影响了上线质量。

当出现了提测delay的苗头，开发人员一定要及时反馈出来，由组长或者经理协调资源，进行补救。这里要重点强调的是，一个功能的提测，是涉及到前端、后端的，你想自己加班到深夜赶进度也是没用的，一定要以最快的速度，将问题暴露出来，由上级去协调一下，留下相关的人一起奋斗一下，尽量保证按时提测。

测试人员测试阶段-看日志

不要以为提测后，就没自己啥事了，最好还是抽少许时间，去测试机器上看看日志，观察和分析一下入参和出参等，看看有没有什么异常或者不合理的数据。

尽量避免bug的一些手法相关推荐

硬核！尽量避免 BUG 手法
最近参与了几个需求开发,BUG很少,有些需求没BUG,有些才一个BUG,搞的测试人员还发牢骚说: " 大佬,你负责的项目,bug都少的可怜,叫俺怎么活? 哈哈,其实测试人员要感谢我才对,因为 ...
一个历时五天的 Bug
一个程序员在没有成长成为架构师之前,几乎都要跟 Bug为伴,程序员有很多时间都是花在了查找各种 Bug上. 我印象深刻的一个Bug, 是一个服务器网络框架无锁队列的 Bug .那个 Bug 连续查找了 ...
程序员怎么样保证自己的程序没有BUG
毫无疑问,程序员是善于思考问题的一族.一个程序的编写都是通过:思考.设计.编写.调试.测试以及运行这些基本的阶段. 但大部分程序员都有一个问题,就是不太愿意测试自己的代码.他们草草的调式完成以后就认为 ...
php程序员写bug,程序员的修炼-我们为什么会编写BUG
在最近的一周,我维护的业务系统出现了很多坏毛病,一周七天crash掉了4次,每次都需要都是因为一点很小的问题,触发了蝴蝶效应,导致整个系统全盘崩溃,于是产生除了叙述本篇的想法,当然这并不是为了掩盖我在 ...
程序员求助：被领导强行要求写Bug该怎么办？网友的回答让我笑翻
戳蓝字"CSDN云计算"关注我们哦! 相信大家都知道程序员在写代码的时候,一般都会尽量避免出现Bug,因为一旦代码中出现Bug就证明这段代码运行的时候会有极大的概率出错,会给公司带 ...
软件测试Bug管理规范
概述编写目的本文档定义bug的整个生命周期,规范bug的管理流程.Bug在流转的过程中有章可循.规范bug严重等级与bug解决优先级,使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以 ...
一个历时五天的 Bug，是如何被灭的？
作者 | 大飞本文经授权转大飞码字一个程序员在没有成长成为架构师之前,几乎都要跟 Bug为伴,程序员有很多时间都是花在了查找各种 Bug上. 我印象深刻的一个Bug, 是一个服务器网络框架无锁队列 ...
面试某东测试岗：“如果开发的Bug比较多，你会如何处理？”
Time will tell. 从开发周期到维护周期都可能存在 bug ,只要从事软件开发就会有 bug 的存在. 但是能力高的人,写的代码框架相对 bug 会少很多,初级或者水平差的做出的东西 bu ...
写代码时如何减少 Bug 的产生？
虽然今天仅仅是 1 月份的第四周,但其实今年的工作已经开始收尾了.从下周一开始,你就回发现周围的同事逐渐变少.对于大多数漂泊在一线城市的程序员来说,一年回家的次数屈指可数.所以,很多人已经归心似箭了- ...

尽量避免bug的一些手法

概述