每天總結一個小知識點，工作小記第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和構造器模式，就能簡化不少的數據庫操作代碼，自主可控。對於長期迭代維護的項目，核心組件選用開源基金會的產品，相對更穩定。不用擔心項目突然停滯或者未來發展方向的變化。
在項目重構之旅中，我對前人在框架選型上持不同意見，認為選型不當是項目后續維護困難的一個重要原因。在此重構之際，總結如上，歡迎大家批評指正。