背景：
最近维护一个老旧工程，遇到集团层面的数据安全改造，需要在DAO层做加解密改造。而这个老旧工程的DAO层是用的JdbcTemplate实现的，尽管template方式实现起来可自由发挥的空间很大，但是因为跟其他其他服务的技术栈不统一，无法实现统一加解密，所以考虑把JdbcTemplate升级到Mybatis。
过程：
升级的关键问题就是原来的 xxDaoImpl类里写了大量的业务逻辑（显然，程序员们在这里没有很好的遵循开发规范），而Mybatis是通过对Dao接口做动态代理并映射到 xxMapper.xml上的（底层是用的JDK动态代理，不能直接对实现类做增强，所以只能改成接口的方式），那么DAO大段大段的逻辑将无处安放，需要做迁移，要么往上迁到service层，要么通过Mybatis的动态sql转换到xml里，然而很不巧的是这个老旧工程是个核心工程，很多服务都直接依赖了它（Dao层依赖），所以把业务逻辑都往上提的话又是一项巨大的工程而且没法保证逻辑迁移时的正确性，对测试的同学来说又是一场灾难（因为我们给出的测试范围就是：所有业务都要测。。）
经过一番抓耳挠腮后，灵机一动想到了default方法（当初JDK团队引进这个特性就是为了兼容扩展已有接口），我们遇到的场景跟default方法的使用场景非常匹配，把 xxDaoImpl改成接口后，还可以把那一坨一坨的逻辑留在DAO层，而且经过测试，default方法也是可以被代理增强的，所以不会影响Mybatis的Interceptor，也不会影响统一的加解密安全改造。
（截图里还用到了Mybatis-plus，Mybatis的好CP，给他们打个硬广：https://mp.baomidou.com/guide/）
至此：
目前升级改造的技术方案已经验证完毕，再说点感想吧：有时候自己想想，上面的方案有点点Hack的精神，虽然通过技术解决问题是程序员最大的满足和自豪，但是软件、系统、项目等等终究是工程化的东西，按照正常的演进思路就是应该做重构，让编码更符合规范，也为以后的框架升级留够足够的兼容性。但是，作为互联网项目，生命周期短以及朝不保夕是家常便饭的事情，而且一般都是以业务为驱动的，公司要的是爆发式的增长，对技术团队的要求就是能快速响应，持续交付性能强大基本可靠的产品，而对于产品本身的规范性并没有思考的太多，不像传统的大型软件项目，严格按照瀑布模型来工程化的演进。