（精华）良好的编码习惯

水深无声 2023-01-06 01:17 186阅读 0赞

1、修改完代码要自测  
2、方法入参都要校验：例如长度、是否为空  
3、修改老接口的时候，思考接口的兼容性。  
4、对于复杂的代码逻辑，添加清楚的注释  
5、使用完IO资源流，需要关闭  
6、代码采取措施避免运行时错误（如数组边界溢出，被零除等）  
7、尽量不在循环里远程调用、或者数据库操作，优先考虑批量进行。  
8、写完代码，脑洞一下多线程执行会怎样，注意并发一致性问题  
9、获取对象的属性，先判断对象是否为空  
10、多线程异步优先考虑恰当的线程池，而不是new thread,同时考虑线程池是否隔离。  
尽量不要所有业务都共用一个线程池，需要考虑「线程池隔离」。就是不同的关键业务，分配不同的线程池，然后线程池参数也要考虑恰当。  
11、手动写完代码业务的SQL，先拿去数据库跑一下，同时也explain看下执行计划  
12、调用第三方接口，需要考虑异常处理，安全性，超时重试这几个点。  
异常处理（比如，你调别人的接口，如果异常了，怎么处理，是重试还是当做失败）  
超时（没法预估对方接口一般多久返回，一般设置个超时断开时间，以保护你的接口）  
重试次数（你的接口调失败，需不需要重试，需要站在业务上角度思考这个问题）  
简单一个例子，你一个http请求别人的服务，需要考虑设置connect-time，和retry次数。  
如果是转账等重要的第三方服务，还需要考虑「签名验签」，「加密」等  
13、接口需要考虑幂等性  
接口是需要考虑幂等性的，尤其抢红包、转账这些重要接口。最直观的业务场景，就是「用户连着点击两次」，你的接口有没有hold住。  
一般「幂等技术方案」有这几种:  
查询操作  
唯一索引  
token机制，防止重复提交  
数据库的delete删除操作  
乐观锁  
悲观锁  
Redis、zookeeper 分布式锁（以前抢红包需求，用了Redis分布式锁）  
状态机幂等  
14、多线程情况下，考虑线程安全问题  
使用一些线程安全的类  
15、主从延迟问题考虑  
先插入，接着就去查询,这类代码逻辑比较常见，这「可能」会有问题的。一般数据库都是有主库，从库的。写入的话是写主库，读一般是读从库。如果发生主从延迟，很可能出现你插入成功了，但是却查询不到的情况。  
16、使用缓存的时候，考虑缓存跟DB的一致性，还有（缓存穿透、缓存雪崩和缓存击穿）  
缓存雪崩：指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。  
缓存穿透：指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。  
缓存击穿：指热点key在某个时间点过期的时候，而恰好在这个时间点对这个Key有大量的并发请求过来，从而大量的请求打到db。