近期工作中的一些總結

（1）三層模板和流程
我發現很多東西其實吧，三層就是一個模板和流程；
正向推，從控制層開始，反向從內個sql開始寫，大部分應該就是從xml文件開始的，然后寫到控制層，畢竟這中間都是方法的調用。

假如先看了前端的接口文檔吧，比如要返回什么鬼東西先看一眼；
然后咱們就是說去控制層開始用注解吧；@restcontroller，這種集合性注解；
然后@requestmapping寫好請求路徑，然后設置好類；繼承誰，這個可以自己寫個大類，就是有所有的基礎請求的這種，這個我進階的時候可以多看看；
1.寫好對前端的接口定義好路徑：然后里邊寫好要用的方法，看看要返回什么，比如前端要一個返回用戶列表的數據吧；我們的起名肯定就是getUser()類似這種
2.第二步，我們現在去服務層實現，我們去服務層寫個接口就和這個方法名字一樣，然后我們里面就寫好抽象方法我們再繼續，去impl實現層里面實現；
3.實現層我們用到這個方法重寫，里面就是返回這個實體類的所有數據，寫個return就行了，這個實體類放到集合里面返回，或者直接返回這個實體類的對象？
4.我們去定義實體類，我們這里肯定是user類了，里面id什么的弄好，然后mapper里面寫接口，xml里面寫對他的sql，用mybatis去映射；
5.然后我們把sql寫對，執行一下，去內個數據庫里面查一下，能查出來就代表差不多了，其實最重要的就底層邏輯；
6.去前端檢驗index.ts接口路徑是否正確；然后前端的ts里面的字段是否都對都包含。
7.檢查完畢之后我們就是去dom里面改，然后把值傳對，請求寫對；

前端請求 → Controller → Service接口 → Service實現 → Mapper接口 → XML映射文件 → 數據庫
↑
返回數據 ←───────────────────────────────────

后端請求 → 前端接口→ 前端ts對應 → 前端vue頁面（dom，點擊事件，事件邏輯綁定）-> 渲染

其實最重要的就是咱們sql要寫好，一個sql就能把查出來的很多東西送進vo類里面；理解的太少了；最好的思路就是從sql到mapper到service

（2）接口復用性
就是一個接口他可以用很多很多很多次；非常多次，比如你做了分頁查詢吧，下拉框里面根據特殊值查詢吧，這種都可以用百萬次，而且尤其是用內個id查詢數據，你不管什么都是用id，保存其實也是，只是前端給她翻譯成字段了，你看著以為是名字，所以要多打斷點，多看返回，多理解，然后多看代碼；更別說，那種增刪改查，你寫好一個，別的頁面照抄就完了， 主要是邏輯性要很強；根據業務需求來；需求真的多到爆！然后就是，寫好了還一會得變，不停的要改；所以根本就是，在寫一個初始接口的時候就得寫好，做一個最大的功能，其實就在于怎么設計了，如果你底層設計的不好，后面業務開發搭建起來全是bug；

（3）git的使用
就是這個東西吧，他真的就是，很復雜，很煩，很麻煩，你上傳了個東西，別人改一樣的地方，就沖突，先提交到本地再推送，就容易忘，最好寫一個接口測試了沒問題就提交，不然多了你根本看不過來，多提交幾次，備注打好，每次就一小部分就行了；這樣也利于維護，最好遵守規則，寫看的懂的代碼，不然，更亂，亂種亂；

（4）拿到一個業務先分析，一定要分析好
分析業務需求很重要，比如，現在要加載一個下拉框了吧，就是需求是，你這個下拉框里面有別的表的數據，然后呢，前端用戶點擊，點擊之后我獲取到用戶的選擇和id吧，然后拿到這個值以后，我去根據這個值去查詢我對應的信息；這怎么辦？先說我的思想：
1.我們需要先對應表建立vo，和實體類，我先把東西查到，查到了我才能返回對吧，返回返回成什么格式呢？就比如這個下拉列表里面要展示的是資產列表，那我就得有個資產表的實體類，然后我去對應建立，然后我給她@data，構造函數和tostring吧，然后全部設置好。那是不是就是封裝成這個vo類返回嗎；然后返回給mapper給服務層，給控制層，層層返回，然后；就前端拿到了，
2.現在是不是該去xml文件里面寫sql了，就是Mybatis,的東西然后做好映射；

（5）解決問題的能力和歸類
遇到問題bug不要慌，一定要有特別足夠的耐心，然后從源頭找，或者報錯丟給ai，ai分析完代碼返回，找清楚是什么問題誰的問題，效率會更高，再一個就是要多自己手寫，自己手寫的多了，才能加倍理解，時間緊迫的現在，加上各種

（6）多交流討論
一定一定要多交流討論問題，這個東西他原型也有可能會出大問題出錯；出很多很多的毛病，遇到很多不清楚的地方就改，然后就是做好一個接口，沒問題就提交

（7）總結，然后手敲
一定一定要多交流討論問題，這個東西他原型也有可能會出大問題出錯；出很多很多的毛病，遇到很多不清楚的地方就改，然后就是做好一個接口，沒問題就提交，多多熟悉