尽量避免bug的一些手法 原 荐

概述

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

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

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

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

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

尽量避免bug的手法

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

需求阶段

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

代码设计阶段

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

代码开发阶段

必须写单元测试

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

但是单元测试一定要认真负责的写，尽量覆盖主流程业务。那种随便写写，随便验证的单元测试，不写也罢，没啥意义，还浪费时间。

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

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

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

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

必须做开发联调

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

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

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

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

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

原文链接

尽量避免bug的一些手法