友情推荐:15个写代码的好习惯

2021-09-24 15:12:39  晓掌柜  版权声明:本文为站长原创文章,转载请写明出处


一、前言

    在开发的过程之中,我们或多或少都会遇到、甚至是写一些BUG,有的是分工协作出现偏差,有些是自己开发经验不足,也有些是自己不好的代码编写习惯。本文这里整理了15个在代码编写时的好习惯,希望能对各位有所帮助。


二、自测

    自测是我们在功能代码编写后需要进行的一个重要步骤,也是开发者的基本素养。简单来说:我们要对自己写的东西负责!当你写的代码连你自己这一关都过不了,又怎么能苛求能让测试人员、功能上下游的同事甚至是线上业务能给你一个稳定且友好的反馈呢?

    业务不是一成不变的,我们也经常会对一些小的功能模块进行优化改动,很多开发人员(甚至是一开始的我)都是对自己修改的这一点点功能信心十足:我就改动了几行代码或者增加了几个属性,就不用做测试了。单结果往往是比较打脸的,一个小小的改动也有可能会牵动全局。当这个蝴蝶效应被引发时,你看着测试和开发同事提过的BUG简直社死了...

    所以,功能开发后不管涉及面有多大都是要进行自测的。我们可以根据实际情况选择自测的范围:是当前功能的测试,还是当前模块的测试,亦或是整个业务链的全流程测试。


三、方法入参校验

    我们在方法中进行业务处理之前,一定是要进行参数校验的。比如:

    ① 某个参数是否允许为空值

    ② 参数的长度、数据类型是否满足需求

    ③ 参数的边界值是否OK

    ④ 参数的数据是否合法,状态上是否满足

    如果我们在业务处理是不做参数校验,会导致在进行数据库操作时直接异常抛出,甚至是在多重业务处理时中间业务进行出现问题而产生脏数据。所以参数校验也是一个重要的保护措施,值得我们每一个人去重视!


三、有意识的去规避异常

    我们在开发中会遇到各种异常,比如:数据越界、空指针、方法找不到、数学计算异常、类型转换异常等。所以我们要在可能存在异常的地方做规避处理,在产生异常的情况下及时做规避处理,比如:

    ① 获取数据信息时先检测数据条目、数据状态

    ② 链式调用时尤其注意NPE问题

    ③ 集合数据处理时,先判断是否为null值、是否长度为0


四、合理使用循环

    ① 不要在循环中进行远程调用

    ② 数据循环有删除操作时,倒序处理

    ③ 不要在循环中使用try catch


五、属性信息操作

    这一点是和第三点是差不多的,我们很多的NPE都是这种情况导致的,比如:获取了ID为666的用户信息,然后比对name是否为“张三”,当没有用户信息返回时,马上就空指针异常了。所以我们在对象获取后对对象的属性进行操作时一定要检测一下对象是否为空!


六、修改旧代码时考虑兼容旧业务

    这个是我们经常会遇到的一个场景了:随着业务的变更以往的业务增加的新的情况,这时候我们肯定是要对旧的接口进行更改的。以参数增加为例,当接口需要增加一个参数时,旧的方法也要同步更新的。在分布式的项目中如果擅自修改了接口的参数,一旦上线就是史诗级的灾难了。


七、良好的代码注释

    一直以来都有两种说法:1、代码是给人看的。2、代码是给机器看的。我认为准确来说代码是给机器执行,给人看的!所以比较建议在开发过程中做好注释工作。尤其是在复杂业务逻辑处理时尤其要注意,这对别人阅读并维护你的代码有很大的帮助,也十分利于后期的维护工作展开。有一句话说的好:这段代码是做什么用的一个月前只有我知道,但是一个月后只有上帝知道了!


八、IO操作进行完毕及时关闭

    windows系统桌面如果打开太多文件或者系统软件,就会觉得电脑很卡。同样,我们的服务器平时操作文件,或者数据库连接,IO资源流如果没关闭,那么这个IO资源就会被它占着,这样别人就没有办法用了,这就造成资源浪费、系统卡顿。所以我们在IO操作时,在finally中要对IO资源进行关闭。


九、重视多线程处理

    我们经常见的一些业务场景,就是先查下有没有记录,再进行对应的操作(比如修改)。但是呢,(查询+修改)合在一起不是原子操作哦。处理不当就会产生脏数据了。所以写完代码后想一下,如果是多线程的情况下这段代码会不会存在并发一致性问题。


十、多线程操作时优先使用线程池

    使用线程池的好处:
    ① 它帮我们管理线程,避免增加创建线程和销毁线程的资源损耗。
    ② 提高响应速度。
    ③ 重复利用。
    同时呢,尽量不要所有业务都共用一个线程池,需要考虑线程池隔离。就是不同的关键业务,分配不同的线程池,然后线程池参数也要考虑恰当。

十一、多线程情况下注意集合的线性安全问题

    在高并发情况下,HashMap可能会出现死循环。因为它是非线性安全的,可以考虑使用ConcurrentHashMap。所以这个也尽量养成习惯,不要上来反手就是一个new HashMap();

    PS: ① Hashmap、Arraylist、LinkedList、TreeMap等都是线性不安全的;
          ② Vector、Hashtable、ConcurrentHashMap等都是线性安全的


十二、使用缓存时,注意数据一致性问题

    使用缓存可以使我们的业务查得快,资源消耗降低。但是尤其要注意缓存与数据库的一致性问题。同时还需要规避缓存穿透、缓存雪崩和缓存击穿三大问题。

    ① 缓存雪崩:指缓存中数据大批量到过期时间,而查询数据量巨大,引起数据库压力过大甚至宕机
    ② 缓存穿透:指查询一个一定不存在的数据,由于缓存是不命中时需要从数据库查询,查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到数据库去查询,进而给数据库带来压力
    ③ 缓存击穿:指热点key在某个时间点过期的时候,而恰好在这个时间点对这个Key有大量的并发请求过来,从而大量的请求打到数据库


十三、接口幂等性

    接口是需要考虑幂等性的,尤其抢红包、转账这些重要接口。最直观的业务场景,就是用户连着点两次,你的接口可能出现问题了!在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果的函数。

    一般幂等技术方案有这几种:
    ① 查询操作
    ② 唯一索引
    ③ token机制,防止重复提交
    ④ 数据库的delete删除操作
    ⑤ 乐观锁
    ⑥ 悲观锁
    ⑦ Redis、zookeeper 分布式锁
    ⑧ 状态机幂等

十四、三方接口对接

    调用第三方服务,或者分布式远程服务的的话,需要考虑:

    ① 异常处理(比如,你调别人的接口,如果异常了,怎么处理,是重试还是当做失败)
    ② 超时(没法预估对方接口一般多久返回,一般设置个超时断开时间,以保护你的接口)
    ③ 重试次数(你的接口调失败,需不需要重试,需要站在业务上角度思考这个问题)

    PS:你一个http请求调别人的服务,需要考虑设置connect-time,和retry次数。如果是转账等重要的第三方服务,还需要考虑签名验签,加密等。之前写过一篇加签验签的,有兴趣的朋友可以看一下哈

十五、优化你的SQL

    写完业务代码的SQL后,先把它拿到数据库跑一下,看看有没有明显的语法错误。切勿写完就把代码打包上去测试服务器。同时呢,也用explain看下你Sql的执行计划,尤其走不走索引、是否全表扫描等。


更多精彩请持续关注:guangmuhua.com


最新评论: