上一篇列举了一些比较常见的Code Review问题列表，文末有链接，可追溯查看。本篇为上篇的姊妹篇，继续列举一些上篇遗漏的或不易发现的问题清单，希望能整体性把一些常见的问题表述出来。
测试数据不具有代表性，导致功能分支测试覆盖率不够，真正提交测试时很容易暴露出问题，对已对人都不好。
事务使用不合理，是否在事务方法中调用外部服务。有些在只读事务操作数据，在启用事务配置时要特别注意，应避免此类操作。
对于关键数据未进行为空判定，一个空NullPointer异常足以打乱所有正常的业务逻辑走向。
涉及分布式系统间交互数据时，无补偿机制来保证数据的最终一致性。也就是说非正常情况下的保障措施缺失。
系统间关键交易交互时，无交易记录留存，后期数据分析、系统间数据核对基本无从下手，造成一些不弥补的损失。
与第三方系统接口交互，仅考虑同步数据返回，异步数据返回未编写对应方法，导致一部分业务场景下数据不一致。
异常信息处理欠妥当，直接将错误信息返给前端用户，体验较差。此类信息需要包装，尽量对用户友好。
从文件布局考虑，包结构、文件目录结构等安排不合理，文件存放错乱，统一职能文件未能统一规范摆放存储，这给后续系统维护增加难度。
从单个功能处理看，很正常，但推演到全局功能来讲，有些功能类型或流程相同，可以采用模板模式等前人抽象出来的设计模式来重构，提升代码的精简性。
对于后期可能发生变更的功能，缺少潜在可见的扩展性，这个可事先规划好，完全可以兼容可以预见的变更。
代码兼容性比较弱的或者有些淘汰不建议的方法依旧在使用，建议换成兼容性较好的方法或替代方法，一旦时间长远，这些不再兼容，极易引起bug。
多线程中使用了一些线程不安全的对象，比如常见的日期数据格式化类SimpleDateFormate，建议采用concurrent工具包里面的或Guava里面的方法或实体。
采用数据库进行共享锁操作时，存在漏洞。先select再update时有时间空档，容易被其它线程更改数据。应直接采用update的方式直接拿数据，如update table set colum=1 where colum=0
最后一条，也是比较关键的一条。代码逻辑正常，但与业务逻辑不符，好比此处需要一个螺母固定，却放了把瑞士军刀，虽然很强大，但无用。此类问题隐藏较深，所以需要Review人员经验丰富且对业务熟知，否则仅是经验丰富也很容易遗漏掉，造成题不对文的局面。
这两篇内容是笔者实际工作中总结出的几点经验，肯定还有其它Code Review过程产生的其它问题文章里没有提及到的，有兴趣的朋友可以留言在文章底部，把问题抛出来，群策群力不失为一个进步的好办法。
上一篇传送门：常见Code
Review过程中发现的问题
基于SpringCloud的Microservices架构实战案例
Spring
Boot + Elasticsearch 实现索引的日常维护
