周会上同事抛出了一个问题,程序员如何减少开发中的 Bug?很有意思的一个话题,本篇文章我们来进行探讨与总结。
爱因斯坦曾经说过:「如果给我一个小时解答一道决定我生死的问题,我会花55分钟来弄清楚这道题到底是在问什么。一旦清楚了它在问什么,剩下的5分钟足够解答这个问题。」
虽然我们软件开发过程不会面临生死的抉择,但是却直接影响着用户的 使用感受 ,决定着产品的走向。所以程序员如何减少开发中的 Bug,既反映了 代码质量 ,也反映了个 人综合能力 。
那么我们该如何有效的减少开发中的 Bug 呢?
我觉得应该从两方面说起:业务层和代码层。
软件开发过程我们就不细说了,直接来看最重要的几个节点:
1.需求讨论阶段
一定要明确需求, 测试,开发,产品三方务必达成一致 。前期如果存在没有明确的问题,那么后期就会造成无效返工和不必要的争执,这在日常开发尤为常见。
所以,软件开发前期,我们都会进行「评审,反讲,评估」三个阶段。
2.开发完成阶段
开发完成后,程序员首先要完成「自测」,也就是软件开发中的「冒烟测试」,确保主流程无误。否则,在开发工程师提交代码后,测试工程师步履维艰,无法有效开展测试,会造成极大的资源浪费。
更规范的流程需要测试工程师在需求明确之后写出「测试用例」,开发工程师在完成开发后,自行对照「测试用例」完成初步验证,之后就可以代码提测了。
这么做的好处就是既保证了「高质量的代码交付」,同时减少了测试工程师的工作量,我们何乐而不为呢?
3.提测
自测和提测有什么区别呢,从软件开发过程来看,其实开发工程师和测试工程师其实完成了不同阶段的测试:
开发工程师「白盒测试」:
是指实际运行被测程序, 通过程序的源代码进行测试而不使用用户界面 。这种类型的测试需要从代码句法发现内部代码在算法、溢出、路径和条件等方面的缺点或者错误,进而加以修正。
白盒测试需要从代码句法发现内部代码在算法,溢出,路径,条件等等中的缺点或者错误,进而加以修正。
测试工程师实际进行的是「黑盒测试」。那么什么是「黑盒测试」呢?
黑盒测试也称功能测试,它是通过测试来检测每个功能是否都能正常使用。在测试中,把程序看作一个不能打开的黑盒子, 在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试 。
它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。 黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试 。
黑盒测试是以用户的角度,从输入数据与输出数据的对应关系出发进行测试的。
很明显,如果外部特性本身设计有问题或规格说明的规定有误,用黑盒测试方法是发现不了的。黑盒测试法注重于测试软件的功能需求,主要试图发现下列几类错误。
更多细节请查看文章: 黑盒测试
代码层面,我们需要从以下几方面来说起:
1. Eslint 规避低级语法问题
这个显而易见,编写代码过程发现问题,避免因为简单语法,如:漏写了逗号,变量名写错,大小写问题等
2. 边界处理
做好容错,必要的判空,还有就是代码边界问题。多想一想如果数组不存在,我们如何处理?如果数组越界,我们如何修复?如果数据缺失,我们如何使页面不崩溃?
3. 单元测试
如果时间允许,我们可以做好单元测试,每次编译代码,或者提测前启动脚本,确定测试脚本都覆盖到了核心代码,尽可能减少代码出错率。
4. 积累
为什么说要积累,其实道理很简单。随着开发经验的增长,你可能会碰到很多问题,那么如果细心积累,其实很多错误在不知不觉中就被处理了。反之,你会不断的掉入同一个坑里,在进坑与出坑中迷失自我。那么我们如何积累呢?
首先,碰到自己不会的问题,如果第一时间没有解决,通过查找或者请教别人解决了,那么一定要用小本本记下来,最好使用云笔记。好处不言自明。
其次,要积累自己的函数库,我们经常用到的一些方法,不妨自己做一个封装,不断沉淀。也许有一天,你会发现,自己不知不知觉中写出了一个 Lodash 函数库。
最后,你可以积累优秀的代码片段,嗯,「我们不生产代码,只是优秀代码的搬运工」。
5.学习
一句话,没有什么比学习优秀开源代码更有趣的事情了。 阅读优秀源码,学习作者思想,站在巨人肩膀上,你才能走的更远!
做好上面这些,相信你一定会是一位出色的工程师。
对于这类开放问题仁者见仁,智者见智,我相信每个人都会有自己的看法,也会有自己一套独特的方法。 不管黑猫白猫,能抓住老鼠的就是好猫 。对于程序员来说,能减少 Bug 的方法就是好方法。
程序员群体流传一句话:不写代码就有没有 Bug。
我们不能因为怕犯错误而减少写代码,更应该知难而上,越挫越勇。要知道日常开发中 「Bug 是不可避免的,只能减少」。
当然,这不应该成为我们写出 Bug 推脱的理由。不断超越,方是永恒。
原文 http://jartto.wang/2019/08/24/how-to-decrease-bugs/
JavaScript语言设计太灵活,用起来不免要多加小心掉进坑里面。如今网站几乎100%使用JavaScript。JavaScript看上去是一门十分简单的语言,然而事实并不如此。它有很多容易被弄错的细节,一不注意就导致BUG。
和你们一样,我也是一个普普通通的前端开发者,在日常工作中,大部分时间不是在写新代码,而是在改代码,或是需求被改了,或是报bug了。当别人想我们报一个bug,直到我们把bug完整的修复好,整个过程是一个怎样的经历?
苍天啊!大地啊!竟然有程序员,因为沉迷代码,快要痛失女友了!那么,程序员写起代码,究竟可以有多沉(shang)迷(yin)?程序员为了写代码,可以有多疯?看了网友们的评论
开发应用程序是一个非常有压力的工作。没有人是完美的,因此在这个行业中,代码中出现bug是相当普遍的现象。面对bug,一些程序员会生气,会沮丧,会心烦意乱,甚至会灰心丧气,而另一些程序员会依然保持冷静沉着
缺陷的定义:软件没有实现产品的说明书所描述的功能、软件实现了产品说明书描述不应有的功能...缺陷的等级-致命:一招毙命的缺陷,使你的系统无法运行,有造成数据泄漏的安全性问题。严重:可以引起易于纠正的异常情况、可能引起易于修复的故障或对产品外观难以接受的缺陷。
在学习ant design的自定义主题这一功能时候,官方给到创建config-overrides.js文件,并且写入如下代码, 查阅资料发现react-scripts 升级到 2.1.2 以后破坏了 react-app-rewired,react-app-rewired的新版本删除所有方法injectBabelPlugin
如今软件开发迭代频繁,随之而来的是产品质量难以保障,用户一天天被动找到 bug 而骂开发,开发要么被拉去祭天,要么拉慢开发新功能的进度条,分出时间精力处理 bug。这已经成了软件开发行业的一大难题,有什么解决方案呢?
当你遇到问题的时候,只能通过debug功能来确定问题,你应该考虑打日志,良好的系统,是可以通过日志进行问题定位的。当你碰到if…else 或者 switch这样的分支时,要在分支的首行打印日志,用来确定进入了哪个分支
有许多可视化的 Bug 跟踪工具,通常可以根据特性集、集成和定价进行分类。选择一个 Bug 跟踪工具时,需要整体考虑团队的规模和需求。对于很多团队来说,项目管理并不是必需的,因此对 Bug 跟踪工具的真正需求变成了一个强大的解决方案提供者
jq中的animate()方法所实现的动画在绑定事件的同时会产生各种类型的BUG,在事件选择的时候我会尽可能的使用mouseenter和mouseleave来避免,mouseover和mouseout所产生的事件冒泡。
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!