虽然我们的软件开发过程并不涉及生死抉择,但它直接影响用户体验,并决定产品的方向。因此,程序员在开发过程中如何减少 Bug 反映了代码质量,并展示了他们的整体能力。
那么,我们如何在开发过程中有效减少 Bug 呢?
我认为我们应该从两个方面入手:业务层和代码层。
业务层
我们不详细讨论软件开发过程,直接看最重要的关键点:
需求讨论阶段
在需求讨论阶段,必须明确需求,并使测试、开发和产品团队达成共识。如果在早期阶段没有明确的问题,后期将导致无效的返工和不必要的争执,这在日常开发中尤为常见。因此,在软件开发的早期阶段,我们将经历三个阶段:“审查、反馈、评估”。
开发完成阶段
开发完成后,程序员需要首先完成“自测”,即软件开发中的“冒烟测试”,以确保主要流程没有错误。否则,开发工程师提交代码后,测试工程师将难以进行有效的测试,导致资源的大量浪费。
一个更标准化的过程要求测试工程师在明确需求后编写“测试用例”。开发完成后,开发人员可以自行对照“测试用例”进行初步验证,然后提交代码进行测试。
这样做的好处不仅是确保“高质量的代码交付”,还可以减少测试工程师的工作量。为什么不这样做呢?
代码提交测试阶段
自测和代码提交测试有什么区别?从软件开发的角度来看,开发人员和测试人员在不同的阶段进行测试:
开发人员的“白盒测试”:
白盒测试是指通过使用源代码进行测试,而不使用用户界面来运行测试程序。这种测试需要通过代码的语法分析发现与算法、溢出、路径、条件等相关的内部编码缺陷或错误,然后进行修正。
测试工程师进行“黑盒测试”:
黑盒测试,也称为功能测试,是通过测试来检测每个功能是否可以正常使用。在测试中,程序被视为一个不能打开的黑盒子,完全不考虑程序的内部结构和特性,只对程序接口进行测试。
黑盒测试只检查程序功能是否按照需求规范文档正常使用,程序能否正确接收输入数据并生成正确的输出信息。黑盒测试关注外部程序结构,不考虑内部逻辑结构,主要针对软件接口和软件功能进行测试。
黑盒测试是一种从用户角度出发,以输入数据和输出数据之间的对应关系为起点进行的测试。
显然,如果外部特性的设计有问题或规范有错误,使用黑盒测试方法是无法发现的。黑盒测试主要针对软件的功能需求,主要试图发现以下类型的错误:
- 功能不正确或缺失;
- 接口错误;
- 输入和输出错误;
- 数据库访问错误;
- 性能错误;
- 初始化和终止错误。
代码层
在代码层面,我们需要从以下几个方面入手:
Eslint 避免低级语法问题
这显而易见。在编码过程中,识别问题,避免诸如逗号缺失、变量名称错误、大小写敏感等简单的语法错误。
边界处理
确保容错性,必要的空值检查,并解决代码边界问题。考虑如何处理不存在的数组或数组越界等场景。如何防止页面因数据丢失而崩溃?
单元测试
如果时间允许,进行彻底的单元测试。在每次编译代码或部署之前运行测试脚本,确保核心代码被测试覆盖,并尽量减少错误率。
积累为什么要谈积累?原因很简单:随着开发经验的增加,可能会遇到许多问题。通过细心地积累知识,许多错误可以在不知不觉中得到解决。否则,将不断陷入同一个陷阱,并在其中迷失。那么我们如何积累?
首先,当遇到无法立即解决的问题时,如果通过研究或向他人寻求帮助解决了问题,请务必记下在笔记本中,或者更好的是使用云笔记以便随时访问。
其次,构建函数库,通过封装常用方法进行不断完善。也许有一天会发现自己不知不觉地创建了自己的 Lodash 库。
最后,积累优秀的代码片段;“我们不生产代码,我们只是优秀代码的搬运工。”
学习
简而言之:没有什么比从优秀的开源代码中学习更有趣的了!阅读优秀的源码不仅可以让我们学习作者的思想,还可以让我们站在他们的肩膀上走得更远!
结语
关于这样一个开放性的问题,每个人可能会有不同的意见,智者见智。每个人都有自己的观点和独特的方法。不管是黑猫还是白猫,只要能抓住老鼠就是好猫。对于程序员来说,任何可以减少 Bug 的方法都是好方法。
程序员常说:“没有代码,就没有 Bug。”
我们不应因为害怕犯错而减少编码,而是要勇敢地面对挑战,并在面对挫折时更加坚定。重要的是要理解,Bug 在日常开发中是不可避免的,只能尽量减少。当然,这不应该成为我们将 Bug 归咎于他人的借口。不断超越自我是走向永恒的关键。