总结:开发容易出Bug的代码或操作

简介: 又有一段时间没有发表文章了,感觉在同一个公司待久了,能写出来的东西就少了,呵呵,大家是不是有一样的感觉。 今天来总结一下开发常见的易引发错误或影响效率的东西。

又有一段时间没有发表文章了,感觉在同一个公司待久了,能写出来的东西就少了,呵呵,大家是不是有一样的感觉。

 


今天来总结一下开发常见的易引发错误或影响效率的东西。

开发对于懂开发的人来说其实很简单,做开发这项工作简直就像日常吃饭一样熟练,但是,开发过程中,由于各种各样的问题,例如:业务逻辑不清晰、开发人员粗心、开发人员经验不够、生产环境不同等等,这些问题导致各种BUG,是需要特别重视的,下面整理了一些情况来说明问题。


svn文件漏提交影响他人开发,这个在实际开发中出现比较频繁.

A:漏提交文件(自己不知道,他本地代码编译没报错)

B:获取编译报错,在群里大叫“谁的代码,编译不过”

…………过了半天没有回答,去查下svn提交记录,查出是A提交后就出问题了

B: QQ群里,@A,你提交的有问题,自己去看下”

A: 看下自己果然有文件没提交,赶紧把漏提交的文件提交了,在群里回复“可以了,再获取下”

……然后,就ok了。

 

 

非空判断

B2bDistributorOrderMapping distributorOrderMap = allDistributorOrder.Where(o => o.OrderId == order.OrderId).FirstOrDefault();

var amount =  distributorOrderMap.CreditAmount.GetValueOrDefault(0M);//如果distributorOrderMap为空,则必定报错


循环内多次连续读取数据库-最大可能导致数据库服务器cpu

while (hasData)//每天订单数10000的情况下

{

var orderListQuery = OrdersRepository.Entities.Where(o => o.CheckInDate <= usedDate && (o.FinanceReceiptDate >= usedDate || o.CheckOutDate >= usedDate) && o.CancelStatus != (int)OrderCancelStatusEnum.OrderCanceled && o.OrderStatusId == audited);

if (loopCount == 0) order = orderListQuery.OrderBy(o => o.OrderId).FirstOrDefault();

else order = orderListQuery.OrderBy(o => o.OrderId).Skip(loopCount).FirstOrDefault();

if (order == null) hasData = false;

else hasData = true;

loopCount++;

}


逻辑不严谨-粗心导致

//正确代码

{

if(a==1) return 100;

else return 0;

}

//错误代码

{

var retVal;

if(a==1) retVal=100;

retVal = 0;

return retVal;

}


测试代码写死临时本地配置(如:192.168.9.220)被误提交,本地测试没问题,一发到线上就报错

 

索引超出范围报错

如:

var a=new int[2]{0,1};//两个元素,下标为01

Var b=a[2];//取下标为2的元素,报错

 

数据库基础数据或网站配置不同

比如:

测试环境数据库加了个字段线上忘记加,或本地config配置文件加、改配置,线上忘记改,造成各种报错,也是最常见的错误。

 

 

高级问题:

环境冲突,未考虑测试环境和正式环境

比如:

测试环境上传文件用cdn传文件:http://cdn.xxxx.com/2016-01-01.txt

正式环境文件也是:http://cdn.xxxx.com/2016-01-01.txt

有可能测试环境刚生成文件,造成文件覆盖,正式环境正好在获取,就获取了测试环境的同名文件内容,造成数据错误。


环境不同导致

比如,财务事务补偿正常的操作流程图:


出错情况的正常情况分析:

 

 

总结:

其实有BUG也是正常的,发现后及时修复就行了,但是如果大量的BUG是因为人粗心或思维不严谨、遗漏等原因造成的,那就太不应该了。

所以平日里,我们开发时必须要考虑仔细,提交前至少保证先编译通过,那样问题就会减少很多。


 

相关文章
|
6月前
|
程序员 测试技术
程序员的“Bug之旅”:为何无法一次性写出完美代码?
程序员在软件开发过程中难以一次性写出完美代码,需要不断修改和调试,即“改Bug”,这是由多个因素共同作用的结果。技术层面的复杂性、管理和流程上的不足以及个人能力和认知的局限性都是导致这一现象的重要原因。然而,这并不意味着无法避免或改进。通过加强需求管理、建立有效的版本控制和测试机制、推动团队知识共享以及鼓励代码审查和自我反思等措施,可以降低改Bug的频率和成本,提高软件开发的效率和质量。辩证地看待这一问题,既要理解其存在的合理性,也要积极寻求改进之道,以实现更好的产品和服务。
58 2
|
6月前
|
测试技术 API
修改bug引入更多bug怎么办?
修改bug引入更多bug怎么办?
128 0
|
6月前
在代码优化过程中,常见的错误和bug包括以下几点
在代码优化过程中,常见的错误和bug包括以下几点
|
5月前
|
JavaScript Java
做小程序时遇到的bug
做小程序时遇到的bug
|
6月前
|
JSON 缓存 前端开发
编写代码前,如何规避尽可能多的前端bug?
编写代码前,如何规避尽可能多的前端bug?
70 0
|
小程序 Android开发 iOS开发
小程序 | 小程序修复了一些bug
前段时间,有朋友反应小程序的今天吃个啥有bug,不能正常使用。
140 0
|
安全 编译器 Go
读<一例 Go 编译器代码优化 bug 定位和修复解析>
读<一例 Go 编译器代码优化 bug 定位和修复解析>
104 0
|
Java
以下代码找bug
以下代码找bug
121 0
|
JSON 前端开发 JavaScript
接口测试平台代码实现137: 小bug集中修复
接口测试平台代码实现137: 小bug集中修复
接口测试平台代码实现137: 小bug集中修复
|
前端开发 IDE 测试技术
接口测试平台代码实现40:修改bug
我们的这个系列已经进行了长达12章成品预览和40章纯开发章节,但是基本还没做过完全一点的测试修复bug章节,每次新开发的功能也仅仅停留在单元/函数层面上的自测。
接口测试平台代码实现40:修改bug