在平常的生活中，我们的每一个好习惯都是一笔财富，养成好的习惯，可以让自己避免许多问题，此理论同样适用于日常的开发编码中，以下是总结的一些要点：
1、修改完代码，记得自测一下
根据需求，编写或者调整了代码，“自测”是每一位程序员必备的基本素养。尤其不要抱着这种侥幸心理：我只是改了一个变量或者我只改了一行配置代码，不会影响到其他功能，而没有自测了，可能在后面会被打脸。改完代码，尽量要求自己都去测试一下，可以规避很多不必要bug的。
2、 方法入参尽量都检验
入参校验也是每个程序员必备的基本素养。你的方法处理，必须先校验参数。比如入参是否允许为空，入参长度是否符合你的预期长度等，这个尽量养成习惯，很多低级bug都是不校验参数导致的。
比如你的数据库字段设置为varchar(16)，对方传了一个32位的字符串过来，你不校验参数，插入数据库直接异常了。
3. 修改老接口的时候，要考虑接口的兼容性。
很多bug都是因为修改了对外的老接口，但是却不做兼容导致的。关键这个问题多数是比较严重的，可能直接导致系统发版失败，新手程序员很容易就犯这个错误了
所以，如果你的需求是在原来接口上修改，，尤其这个接口是对外提供服务的话，一定要考虑接口兼容，特别是APP/或者小程序这种，发版是需要个过程。
4、对于复杂的代码逻辑，添加清楚的注释
写代码的时候，是没有必要写太多的注释的，好的方法变量命名就是最好的注释。但是，如果是业务逻辑很复杂的代码，真的非常有必要写清楚注释。清楚的注释，更有利于后面的维护。但也没必要写得拖泥带水，最好是简洁明了，能写清楚逻辑及背景。
5.、使用完IO资源流，需要关闭
应该大家都有过这样的经历，windows系统桌面如果打开太多文件或者系统软件，就会觉得电脑很卡。当然，我们linux服务器也一样，平时操作文件，或者数据库连接，IO资源流如果没关闭，那么这个IO资源就会被它占着，这样别人就没有办法用了，这就造成资源浪费。
6、代码采取措施避免运行时错误（如数组边界溢出，被零除等）
日常开发中，我们需要采取措施规避数组边界溢出，被零整除，空指针等运行时错误。
7、尽量不在循环里远程调用、或者数据库操作，优先考虑批量进行。
远程操作或者数据库操作都是比较耗网络、IO资源的，所以尽量不在循环里远程调用、不在循环里操作数据库，能批量一次性查回来尽量不要循环多次去查。（但是呢，也不要一次性查太多数据，要分批500一次）
一般在执行这种循环操作的，建议在外面先把数据查回来，在执行里面的逻辑操作。
8、写完代码，脑洞一下多线程执行会怎样，注意并发一致性问题
我们经常见到一些业务场景的开，基本上都是先查下有没有记录，再进行对应的操作（比如修改，或者写入）。但是，(查询+修改)合在一起不是原子操作，脑洞下多线程，就会发现有问题了，在多程下，怎么去保证数据的唯一性。
9、对象获取属性，先判断对象是否为空
这个点本来也属于采取措施规避运行时异常的，但是我还是把它拿出来，当做一个重点来写，因为平时空指针异常太常见了，一个手抖不注意，就导致空指针报到生产环境去了。
所以，你要获取对象的属性时，尽量不要相信理论上不为空，我们顺手养成习惯判断一下是否为空，再获取对象的属性。
10、多线程异步优先考虑恰当的线程池，而不是new thread,同时考虑线程池是否隔离
为什么优先使用线程池？使用线程池有这几点好处呀
它帮我们管理线程，避免增加创建线程和销毁线程的资源损耗。
提高响应速度。
重复利用。
11、 手动写完代码业务的SQL，先拿去数据库跑一下，同时也explain看下执行计划。
手动写完业务代码的SQL，可以先把它拿到数据库跑一下，看看有没有语法错误嘛。有些小伙伴不好的习惯就是，写完就把代码打包上去测试服务器，其实把SQL放到数据库执行一下，可以规避很多错误的。
同时呢，也用explain看下你Sql的执行计划，尤其走不走索引这一块。
12、接口需要考虑幂等性
接口是需要考虑幂等性的，尤其抢红包、转账这些重要接口。最直观的业务场景，就是用户连着点两次，你的接口有没有hold住。
一般幂等技术方案有这几种:
查询操作
唯一索引
token机制，防止重复提交
数据库的delete删除操作
乐观锁
悲观锁
Redis、zookeeper 分布式锁（以前抢红包需求，用了Redis分布式锁）
状态机幂等
以上是一些常见的编码技巧，希望能帮到您。
