好的习惯能减少80%的非业务bug

好的习惯能减少80%的非业务bug,今天分享11个习惯。

1.修改完的代码记得自测一下

这是每一位程序员的必备素养,不要抱着侥幸心理,我只是该了一个变量或者我只是改了一行配置代码。只要是动了代码,尽量要求自己去测试一下,这样可以规避很多不必要的bug;

好的习惯能减少80%的非业务bug_第1张图片

2. 代码不要一片一片的

我见过很多代码一片一片的程序员,导致错误频繁。当你提出来问题之后,他还觉得代码是他自己的个人风格。引发bug的主要原因就是计算返回结果出现问题,但是既没有极端值也没有边界条件,为什么还出错呢?

3. 方法入参尽量都检验

入参效验是每个程序员的必备基础素养了,【必须先校验参数】。比如入参是否允许为空,入参长度是否符合你的预期长度。尽量养成习惯,很多低级的bug都是没有校验参数导致的。

如果你的数据库字段设置为varchar(16),对方传了一个32位的字符串过来,你不校验参数, 「插入数据库直接异常」了。

好的习惯能减少80%的非业务bug_第2张图片

4. 写代码前思维是否严谨

很多开发也觉得思维严谨与否是没有办法定义的,这都是代码量和行业经验积累出来的。其实不是的,如果是因为工作经验不足导致的代码不严谨,我们还有未来去累积避免。但是如果是写了一个接口连验证签名都没有的话,这种就是属于思维不严谨。建议大家在实际工作中养成写计划和文档,外加用思维导图进行梳理。梳理逻辑不是这个代码怎实现,而是逻辑层脱离代码的。

第一步:规划,了解业务之后开始做计划。

第二步:按照计划排期,就算有的公司不要求写文档,但对于程序员来说文档+代码才是一体的。

第三步:配合,哪一个接口需要和谁对接,对接产生的问题一一罗列。

最后才是敲代码,大家以为这样会浪费时间,其实这样的代码非常灵活,就算有需求变更也可以临危不乱。

5. 修改老接口的时候,思考接口的兼容性

很多bug都是因为修改了对外老接口,但是不做兼容导致的。关键这个问题多数是比较严重点的,可能直接导致系统发版失败的。

所以我们的需求是在原来的接口上修改,尤其这个接口是对外提供服务的话,一定要考虑接口兼容。比如dubbo接口,原本只是接收A,B参数,你现在加了一个参数C,就可以考虑这样处理:

//老接口
void oldService(A,B);{
  //兼容新接口,传个null代替C
  newService(A,B,null);
}
 
//新接口,暂时不能删掉老接口,需要做兼容。
void newService(A,B,C);

好的习惯能减少80%的非业务bug_第3张图片

6. 对负载的代码逻辑,添加清楚的注释

写代码的时候,是没有必要写太多注释的。好的方法变量名就是最好的注释,但是如果业务逻辑复杂的代码,是非常要必要写注释的。写的清楚,才方便后面的维护。

7. 使用完IO资源流,需要关闭

​大家也都有过这样的经历。Windows系统桌面如果打开很多文件或者系统软件,就会觉得电脑很卡。Linux服务器也是一样的,平时操作文件,或者数据库连接、IO资源流如果没有关闭,这个IO资源就会被它占着,这样别人就没有办法用了。——这是资源浪费。 ​

好的习惯能减少80%的非业务bug_第4张图片

所以使用完IO流,可以使用finally关闭:

FileInputStream fdIn = null;
try {
    fdIn = new FileInputStream(new File("/jay.txt"));
} catch (FileNotFoundException e) {
    log.error(e);
} catch (IOException e) {
    log.error(e);
}finally {
    try {
        if (fdIn != null) {
            fdIn.close();
        }
    } catch (IOException e) {
        log.error(e);
    }
}

8. 代码采取措施避免运行时错误(如数据边界溢出、被零除等)

日常开发的时候,我们需要采取措施规避【数据边界溢出、被零整除、空指针】等运行错误

类似代码比较常见:

String name = list.get(1).getName(); //list可能越界,因为不一定有2个元素哈

所以,应该「采取措施,预防一下数组边界溢出」,正例:

if(CollectionsUtil.isNotEmpty(list)&& list.size()>1){
  String name = list.get(1).getName(); 
}

好的习惯能减少80%的非业务bug_第5张图片

9. 尽量不在循环里​​​​​​​远程调用,或者数据库操作,优先考虑批量进行

远程操作或者数据库操作都是【比较耗网络、IO资源】的,所以尽量不在循环里远程调用,不在循环里操作数据库,能批量一次性查回来尽量不要循环多次去查。但是也不要一次性查太多数据,要分批次。

remoteBatchQuery(param);

10. 获取对象的属性,先判断对象是否为空

空指针异常非常常见,一个不住就导致空指针报到生产环境里面去了。

所以我们在获取对象的属性时,尽量不要相信【理论上不为空】,我们顺手养成习惯判断一下是否为空,在获取对象属性:

if(object!=null){
   String name = object.getName();
}

好的习惯能减少80%的非业务bug_第6张图片

11. 主从延迟问题考虑

先插入,接着就去查询,这类代码逻辑就比较常见。这可能会有问题!一般数据库都是有主库,从库。写入的话是写主库,读一般是读从库。如果发生主从延迟,很可能出现你插入成功了,但是查询不到的情况。

好的习惯能减少80%的非业务bug_第7张图片

  • 如果是重要业务,需要考虑是否强制读主库,还是再修改设计方案。
  • 但是呢,有些业务场景是可以接受主从稍微延迟一点的,但是这个习惯还是要有吧。
  • 写完操作数据库的代码,想下是否存在主从延迟问题。

程序员补课时间

Java学习路线:黑马程序员Java视频教程从入门到精通(完整版)超千万下载量
python大数据学习路线:Python+大数据开发自学教程_Python+大数据开发视频教程从入门到精通
前端学习路线:Web前端视频教程从入门到精通_
软件测试学习路线:软件测试自学全套教程_软件测试视频教程从入门到精通(完整版)​​​​​​

人工智能开发学习路线:人工智能开发_人工智能工程师_AI人工智能

好的习惯能减少80%的非业务bug_第8张图片

 

你可能感兴趣的:(前端,python,java,java,开发语言)