周会上大家抛出了一个问题，程序员如何减少开发中的 Bug？很有意思的一个话题，本篇文章我们来进行探讨与总结。

爱因斯坦曾经说过：「如果给我一个小时解答一道决定我生死的问题，我会花55分钟来弄清楚这道题到底是在问什么。一旦清楚了它在问什么，剩下的5分钟足够解答这个问题。」

虽然我们软件开发过程不会面临生死的抉择，但是却直接影响着用户的使用感受，决定着产品的走向。所以程序员如何减少开发中的 Bug，既反映了代码质量，也反映了个人综合能力。

那么我们该如何有效的减少开发中的 Bug 呢？

二、业务层

软件开发过程我们就不细说了，直接来看最重要的几个节点：

1.需求讨论阶段
一定要明确需求，测试，开发，产品三方务必达成一致。前期如果存在没有明确的问题，那么后期就会造成无效返工和不必要的争执，这在日常开发尤为常见。

2.开发完成阶段
开发完成后，程序员首先要完成「自测」，也就是软件开发中的「冒烟测试」，确保主流程无误。否则，在开发工程师提交代码后，测试工程师步履维艰，无法有效开展测试，会造成极大的资源浪费。

更规范的流程需要测试工程师在需求明确之后写出「测试用例」，开发工程师在完成开发后，自行对照「测试用例」完成初步验证，之后就可以代码提测了。

这么做的好处就是既保证了「高质量的代码交付」，同时减少了测试工程师的工作量，我们何乐而不为呢？

3.提测
自测和提测有什么区别呢，从软件开发过程来看，其实开发工程师和测试工程师其实完成了不同阶段的测试：

开发工程师「白盒测试」：
是指实际运行被测程序，通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法、溢出、路径和条件等方面的缺点或者错误，进而加以修正。

测试工程师实际进行的是「黑盒测试」。那么什么是「黑盒测试」呢？
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试。

它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误。

• 功能不正确或遗漏；
• 界面错误；
• 输入和输出错误；
• 数据库访问错误；
• 性能错误；
• 初始化和终止错误等；

更多细节请查看文章：黑盒测试

三、代码层

代码层面，我们需要从以下几方面来说起：

1.Eslint 规避低级语法问题
这个显而易见，编写代码过程发现问题，避免因为简单语法，如：漏写了逗号，变量名写错，大小写问题等

2.边界处理
做好容错，必要的判空，还有就是代码边界问题。多想一想如果数组不存在，我们如何处理？如果数组越界，我们如何修复？如果数据缺失，我们如何使页面不崩溃？

3.单元测试
如果时间允许，我们可以做好单元测试，每次编译代码，或者提测前启动脚本，确定测试脚本都覆盖到了核心代码，尽可能减少代码出错率。

4.积累
为什么说要积累，其实道理很简单。随着开发经验的增长，你可能会碰到很多问题，那么如果细心积累，其实很多错误在不知不觉中就被处理了。反之，你会不断的掉入同一个坑里，在进坑与出坑中迷失自我。那么我们如何积累呢？

首先，碰到自己不会的问题，如果第一时间没有解决，通过查找或者请教别人解决了，那么一定要用小本本记下来，最好使用云笔记。好处不言自明。

其次，要积累自己的函数库，我们经常用到的一些方法，不妨自己做一个封装，不断沉淀。也许有一天，你会发现，自己不知不知觉中写出了一个 Lodash 函数库。

最后，你可以积累优秀的代码片段，嗯，「我们不生产代码，只是优秀代码的搬运工」。

5.学习
一句话，没有什么比学习优秀开源代码更有趣的事情了。阅读优秀源码，学习作者思想，站在巨人肩膀上，你才能走的更远！

对于这类开放问题仁者见仁，智者见智，我相信每个人都会有自己的看法，也会有自己一套独特的方法。不管黑猫白猫，能抓住老鼠的就是好猫。对于程序员来说，能减少 Bug 的方法就是好方法。

我们不能因为怕犯错误而减少写代码，更应该知难而上，越挫越勇。要知道日常开发中 「Bug 是不可避免的，只能减少」。

当然，这不应该成为我们写出 Bug 推脱的理由。不断超越，方是永恒。