背景：
最近維護一個老舊工程，遇到集團層面的數據安全改造，需要在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的精神，雖然通過技術解決問題是程序員最大的滿足和自豪，但是軟件、系統、項目等等終究是工程化的東西，按照正常的演進思路就是應該做重構，讓編碼更符合規范，也為以后的框架升級留夠足夠的兼容性。但是，作為互聯網項目，生命周期短以及朝不保夕是家常便飯的事情，而且一般都是以業務為驅動的，公司要的是爆發式的增長，對技術團隊的要求就是能快速響應，持續交付性能強大基本可靠的產品，而對於產品本身的規范性並沒有思考的太多，不像傳統的大型軟件項目，嚴格按照瀑布模型來工程化的演進。