每天总结一个小知识点，工作小记第4回;
正在学习如何把一个东西给别人讲的很简单。
上次我发了第一篇文章【mybatis plus不适合企业级开发】，因为接手重构新项目的任务一段时间了，这里从细节方面出发，做第二次讨论。
首先要说的是：欢迎大家来讨论、批评 。但是我这里没有否定Mybatis plus的意思，任何开源出来的软件，作者都无私奉献了巨大的努力。
讨论背景：对于一个短平快的项目，使用Mybatis plus无疑可以节约很多成本，是合适的。本文的焦点集中在：mybatis plus和大型项目的组件选型适配性上，没有全盘否定Mybatis plus的意思。文章产生的主要出发点：组织重构一个使用了MP框架的项目，但是重构的成本和风险极大。
项目的组件选型适配很重要，特别是一个要持续迭代的大项目，如何控制成本、降低风险、持续迭代都需要慎重考虑。
1、框架的活跃度、维护速度、用户广度。
前几天Spring出现了CVE-2022-22965的RCE漏洞，官方马上给出了方案。一个活跃的项目，用户也很多的话，意味着潜在问题被发现的概率越高，同时也意味着修复速度越快。
如果官方修复不及时，一般也会给出暂时的缓解方案。所以：特别要考虑选型组件的团队实力。
有的客户也有自己的安全检查团队，会指出安全问题，他们关注的是我们产品的修复升级速度，到时候只会对我们产品本身不满意：为什么修复的这么慢？
2、Code review的复杂度上升。
如果使用原生的方式，Mapper的XML和Java代码实现了分离，那么Code review比较轻松。其他人提交上来的Merge Request，可以较为容易地看出SQL代码变更的全貌。特别是查询条件，不当的WHERE会走不了索引，造成性能的急剧下降。目前，从这个用Mybatis plus的项目来看，因为mp框架的灵活性，造成了Code review的成本的显著上升，因为较难review出查询条件的原貌。
3、数据字典 维护的割裂。
数据字典跟公司维护的元数据有关。但造成了割裂完全是因为不良的个人代码风格，但是mp框架的灵活性让不良风格更不易控制。特别是POJO的字段和数据库字段之间的映射，当完全散落在java代码中时。数据字典改动时，需要完整的回归，回归成本较大。
4、对接服务治理、运维监控可能要付出额外的成本。
Mp框架基于mybatis做了加强，但是很多类是进行了复制和重写，特别是mybatis的MapperMethod和Executor等相关的部分。这块可能对Agent插桩造成影响。 如果是通过mybatis的Plugin机制的还好，如果是通过字节码插桩，那么有可能会失效，甚至造成其他的bug。
就跟http框架一样，一定要选用httpclient或者OkHttp框架，不要用其他的小框架。因为我们在接入APM性能监控、Trace全链路、或者中间件的性能监控时，很多监控系统都对主流框架进行了适配，可以字节码增强进行监控。
如果使用了MP框架作为核心组件的一部分，我们还得逐个确认，监控中间件能否正确监控到SQL，修改的字节码是否对MP框架有害（这里只是可能，因为监控厂商只是在拿原生Mybatis进行Agent增强测试，外挂MP框架的情况应该没考虑）。而且后续MP框架升级了，还要再回归测试。这成本很高。
5、采用BaseMapper和构造器模式，就能简化不少的数据库操作代码，自主可控。对于长期迭代维护的项目，核心组件选用开源基金会的产品，相对更稳定。不用担心项目突然停滞或者未来发展方向的变化。
在项目重构之旅中，我对前人在框架选型上持不同意见，认为选型不当是项目后续维护困难的一个重要原因。在此重构之际，总结如上，欢迎大家批评指正。