关于代码规范的思考 -- mybatis篇

关于代码规范的思考 – mybatis篇

最近在进行项目的重构，遇到了很多代码质量相关的问题，简单聊一下我对代码质量的一些思考。
一个统一的良好的规范在现在项目开发中特别重要。
下面是我在工作中遇到的几个感觉不合理的地方：

1. 一个mapper里面出现了多张表相关的sql，并且没有规律。
   带来问题：
   写时一时爽，维护气断肠。如果需要修改某个表的某个字段，修改的时候就会发现好多mapper都需要修改。
   解决思路：
   将相同表的sql放在同一个mapper里面，如果需要修改，只用改一个mapper就行；
   直接使用mybatisplus；
2. 多表联查问题。
   我曾多次碰到过十几张表联查，甚至几十张表联查的，sql语句多达数百行，真不知道应不应该感叹他牛逼。
   带来问题：
   后续的维护极其困难，换成其他人维护，几乎没人愿意看这种sql语句；
   业务如果快速增长，需要分库分表，sql语句就无法使用，需要花很大的精力去拆分；
   如果其中有任何一张表执行操作时候长时间持有锁，整个sql都会被阻塞住；
   大数据量，高并发量会严重的占用资源；
   解决思路：
   如果出现很多的多表联查，需要考虑数据表的设计是否合理，需不需要增加冗余字段；
   能拆分的尽量拆分，如果拆分不了可以考虑其他方式减少影响，比如中间表、缓存。。。。。。
3. sql语句中存在大量达业务逻辑
   现在的开发，为了便于维护，都倾向于将逻辑收到一处
   带来问题：
   方法的命名很难体现出业务逻辑，如果别人错误调用，可能会出现问题；
   如果需要修改逻辑，就得结合sql语句进行修改；
   后续如果更改存储介质，比如mysql换TiDB，有些方法是无法使用的；
   解决思路：
   逻辑收在一处，之后维护也方便。
4. mapper的resultMap定义混乱。
   一般来说mapper的result会定义成下面几种：
   表字段对应方式，方便对表进行操作。
   模型字段对应关系（多表联查时候）
   但是有些业务随意定义mapper，给后面的维护以及代码的复用带来了很大的问题。
   解决思路：
   可以根据实体模型来定义mapper，这样复用性更高。