您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 其他 > 正文

避坑指南:程序猿如何避免线上Bug

发表于:2018-03-26 作者:老峰 来源:iOSTips

没有错误的程序是一则谬论,世间难寻。假设存在着一个没有任何错误的程序,那么这个世界将会不复存在。

----《编程之禅》第四篇(金)第二节

hello world是人类已知的最早的绝无bug的程序,但我们在日常开发中,需求不可能简单到像hello world一样,经常是coding五分钟,debug2小时。在讨论如何减少bug之前我们讨论下哪些场景下容易产生bug。

1、bug产生原因:

a、需求本来就有问题而产生的代码缺陷。这类问题源头是需求或产品这一块没有分析清楚,这个锅产品背,但是作为开发者有必要参与到需求分析这个环节中。

b、代码实现和需求相差很大的缺陷。这类问题也是比较常见的,开发人员的思维与需求或产品人员的思维还是有很大差距的。

c、很复杂的需求代码实现在某些逻辑上有缺陷。这类问题有可能是开发人员不想实现完全,也有可能需求过于复杂,在系统设计阶段就没有分析出所有情况。

d、需求变动后对原有业务代码进行重构,对原有业务不熟悉不了解

e、粗心导致的缺陷,比如条件判断写反,人孰能无过。

f、系统架构上的缺陷。这类问题一般很少,出现的话是大面积的。

g、对框架特性、数据结构、语言不熟悉,导致出现缺陷。

h、外部原因,操作系统或数据源。

那么如何避免产生bug呢,尤其是iOS,提交AppStore审核周期并不短,是否还记得那些惨痛的线上bug经历,半夜起来改bug,提交后审核好几天,所以有必要总结下如何避免bug,下面是我总结的几点心得,欢迎补充

•详细和无歧义的需求规格和业务逻辑

•合理的架构和模块

•清晰明确的模块间接口

•不要复制代码,尽可能抽取共用的部分,重复的代码在修改时容易造成不一致

•不要轻易重构代码,每次重构,尽量做到所重构的业务都在本次QA测试用例的覆盖范围内

•尽量在理解同事业务代码的情况下,更改组内成员的业务代码

•处理边界条件,处理非法的参数,永远不要相信数据的可靠性,考虑到各种逻辑分支

• 限制函数的长度, 编写易读易维护的代码,不过度使用技巧,难以理解的代码很可能在修改中出错

• 使用assert ,正确使用异常处理,捕捉能够处理的异常

万一真的出现了bug也别慌,善用《甩锅大法》, 代码没错接口的错,接口没错SDK的错,SDK没错编译器的错, 编译器没错虚拟机错, 虚拟机没错操作系统错, 操作系统没错,硬件错了,硬件没错还有电磁干扰,总之不要自己背锅哈哈哈,兄得接住这口锅!!

最后我个人认为写出没有bug的程序要在需求不不变的情况下。之所以产品不断的维护有bug是因为后续的需求变更在前期的软件设计中是无法考虑的。由于需求变化,但是又不可能每次变更需求都要重新设计架构和软件,导致软件也在bug发现和消除中循环着来度过软件的生命周期,直到软件下线,所以我们只能不断积累开发经验,培养思维的严密性,养成良好的开发习惯,来减少bug。