修改完代码，记得自测一下
「改完代码，自测一下」 是每位程序员必备的基本素养。尤其不要抱有这种侥幸「心理：我只是改了一个变量或者我只改了一行配置代码，不用自测了」。改完代码，尽量要求自己都去测试一下哈，可以规避很多不必要bug的。
方法入参尽量都检验
入参校验也是每个程序员必备的基本素养。你的方法处理，「必须先校验参数」。比如入参是否允许为空，入参长度是否符合你的预期长度。尽量养成习吧，很多「低级bug」都是「不校验参数」导致的。
如果你的数据库字段设置为varchar(16),对方传了一个32位的字符串过来，你不校验参数，「插入数据库直接异常」了。
修改老接口的时候，思考接口的兼容性。
很多bug都是因为修改了对外老接口，但是却「不做兼容导致」的。关键这个问题多数是比较严重的，可能直接导致系统发版失败的。
所以，如果你的需求是在原来接口上修改，，尤其这个接口是对外提供服务的话，一定要考虑接口兼容。
对于复杂的代码逻辑，添加清楚的注释
写代码的时候，是没有必要写太多的注释的，好的方法变量命名就是最好的注释。但是，如果是「业务逻辑很复杂的代码」，真的非常有必要写「清楚注释」。清楚的注释，更有利于后面的维护，以及新手阅读。
尽量不在循环里远程调用、或者数据库操作，优先考虑批量进行。
远程操作或者数据库操作都是「比较耗网络、IO资源」的，所以尽量不在循环里远程调用、不在循环里操作数据库，能「批量一次性查回来尽量不要循环多次去查」。（也不要一次性查太多数据）
写完代码，脑洞一下多线程执行会怎样，注意并发一致性问题
我们经常见的一些业务场景，就是先查下有没有记录，再进行对应的操作（比如修改）。但是呢，(查询+修改)合在一起不是原子操作，脑洞下多线程，就会发现有问题了，
手动写完代码业务的SQL，先拿去数据库跑一下，同时也explain看下执行计划。
手动写完业务代码的SQL，可以先把它拿到数据库跑一下，看看有没有语法错误嘛。不好的习惯就是，写完就把代码打包上去测试服务器，其实把SQL放到数据库执行一下，可以规避很多错误的。
同时，也用「explain看下你Sql的执行计划」，尤其走不走索引这一块。
接口需要考虑幂等性
接口是需要考虑幂等性的，尤其抢红包、转账这些重要接口。最直观的业务场景，就是「用户连着点击两次」，看接口有没有hold住。