代码走查(codereview)如何执行才能提升代码质量

    作为一名开发工程师，如何提升个人能力、减少bug的发生是一件非常重要的事情，它直接关系到了领导及项目组对你能力的认可。层出不穷的bug静下心来好好归类，无非是需求不明确、配置问题、请求参数问题、数据库读和写时的并发问题、越权问题、幂等性问题，进而导致了数据库锁表、空指针系统异常、内存溢出等现象。
    很多公司都会做代码走查(codereview)，走查过程中更多的是相关人员凭借自身的经验及公司的代码规范制度去检查代码规范、代码性能等。若过程中参与人的经验很丰富，则确实能提升代码的质量，减少bug和事故的发生。若大家的水平都一般般，走查也会趋于一种形式，bug还是会不断的出现。
    本人结合开发过程中的各种bug及事故情况，特总结了如下一些场景，可在代码走查之前先行阅读加强代码质量的意识，同时作为代码走查的checklist点一起排查。

禁止在大循环中逐条调Service，SQL，Redis

• 关于Service的调用
  服务本身：提供批量接口；
  调用方：尽可能的以批量方式调用取代逐条调用，减少系统开销；
  
• 关于SQL的循环调用
  主要针对查询，尽可能的将逐条查询转化为一次查询一个批次，减少与数据库交互次数。
  

禁止3B：Big Transaction，Big SQL，Big Batch

Big Transaction

• 注意点：
  

• 对数据库操作必须使用事务，不能使用自动提交，尽量使用声明式事务；
  
• 让事务尽可能的小,在Service层组装数据，在manager层处理事务；
  
• 不要在事务里调用服务（服务可能阻塞）；
  
• 不要在事务里调用Redis；
  
• 在事务中批量更新要排序，确保多事务并发时，避免资源锁等待。
  

• 详解：
  无论是Oracle、SqlServer还是Mysql，大事务是一定要避免的，大事务容易造成锁资源的长时间占用，从而降低并发性能，增大死锁概率。如下是几种大事务的典型场景：
  

• @Transactional打在Class上，这样类中的所有方法均在事务边界内，容易造成大事务，@Transactional应该控制更精细一些，打到方法级；
  2）在一个事务中要更新多张表，在更新每一张表之前都要处理一堆业务逻辑（查询、运算、调用服务等等），正确的做法应该是将查询、运算和服务调用逻辑提到事务外，事务边界内尽可能只处理表更新操作；
  

Big SQL

• SQL使用：
  

• 尽量不用表关联，如果使用表关联，不要超过3个表join；
  
• 热点数据尽量使用Redis；（比如基础资料）
  
• 尽量不用子查询，不用Exist，不在条件列上使用函数；
  

Big Batch

大批量的查询输出很容易将内存打爆，报表或者打印要分批处理。

图中涉及内容链接：
Java的常用设计模式介绍
Hutool工具类整理官网
持续完善中。。。