你這是寫的什麼項目代碼？毫無設計典範，就從上寫到尾，記流水賬嗎？咱們開發不僅僅要注重開發的效率還要注重開發的質量，這樣寫出來的代碼。能方便後期維護？你代碼執行效率能提升嗎？
前面上級就這樣道出了所以然，自己苦苦寫的成果，到節骨眼上，就這麼沒啦，還得重新修改在提交。心裡面自然是憋屈。但靜靜思考之後，所寫的代碼確實很亂，無任何的考慮，很多細節與開發的技巧都不會注意。
那麼如果說能夠把這個難題克服，自己的思維考慮上與開發的效率都能夠得到提升。 只有對自己有要求才能在原來的基礎上不斷的打磨出新的內容，而不是什麼東西“看好”就收。這還是得自己去學習提升，但結果帶來的是收穫與心理上的觸碰
那到底什麼東西才能夠減少重複的代碼？能夠讓項目結構更加的情緒，達到別人說的高內聚、低耦合呢？這就是本次分享主題-----AOP切面編程
AOP切面編程的由來
在軟件工程裡面，開發項目不單單是直接就寫出來，而是先通過一系列的建模，然後在基於框架開發。在開發過程中為了使項目開發效率高、易維護、易擴展等等特性，一般都會採用OOP編程思想。
但是隨著開發的逐步加深，在代碼的編寫上將會產生很深的耦合性。所以我們會使用到AOP的切面編程解決問題。
例如：編寫操作類，我們需要對每個方法進行接口參數的驗證，如果按照普通的模式那麼每個方法都需要自己編寫一套驗證的規則，這樣代碼冗餘與耦合都非常的高。
因為相同的驗證業務代碼每次都會重新編寫，那麼就有產生冗餘代碼。
因為驗證業務代碼直接與操作控制器建立聯繫，耦合非常高，後期不方便項目維護和拓展，那如果後面要 添加、修改 一個驗證規則就需要全盤修改，費時費力。
而AOP切面編程就是在操作類之外建立相關類庫，類庫的內容就是這些重複寫的代碼規則，然後再提供給操作類執行方法。
為什麼要使用AOP切面編程？
1、剝離重複的代碼，減少代碼冗餘
AOP切面編程重要的思想就是抽離那些重複代碼，然後封裝對應的操作類庫，在動態嵌入其它主業務邏輯代碼中。這樣就不會在每個業務下面反覆的編寫重複的代碼程序，從而減少代碼的冗餘。
例如：銀行系統取款會有一個流程，查詢也會有一個流程
這兩者，都有一個相同的驗證用戶的流程，那如果是把驗證用戶直接通過類庫插入到操作的流程中，是不是就不需要在這個2個流程中再次去編寫業務代碼呢？
2、單一職責集中管理，方便後期維護
接觸過面向對象都知道類設計的單一職責原則。也就是如果我們可以把這些重複的代碼抽取出來，做到統一的管理，同時也會很方便後期的管理和維護，因為提供給業務放的就是一個方法的入口。
就類似打電話，你需要知道電話與電話之間的通訊原則嗎？
它並不會把什麼內容都在寫業務流程中，這些都通過AOP的思想把代碼封裝到了統一的模塊裡面。
例如：後面需要在驗證用戶的判斷中加入新的規則、更改其他業務名稱。都對取款、查詢沒任何的影響。這就是單一職業的好處。專人做專事，不單單是程序，在現實生活中也實用。
3、加深你對編程思想理解，為後期架構做鋪墊
如果說項目開發是技術知識是基礎，那麼好的編程思想就是大家後期發展中能力的決定因素。
就例如：造房子，只追求速度、遮風擋雨的功能，那麼你可的房子可能就是茅草房的效果，如果你想造一個大別墅，那你就需要從地形、建造材料、造型、成本等方面都會充分的考慮。那麼這就是你思考與不思考之間最直接的差別
AOP的思想就是通過橫向來對業務進行拆分，如果你時常去思考，項目中很多的組件、功能業務它都會用到編程思想來進行設計，而不是單獨的只為完成功能。
橫向圖解：
如果現在從業務上開發會考慮到每個業務模塊、模塊功能設計、維護性、拓展性等，那麼在後面面對大型項目時，才可以在複雜的業務場景下，進行設計與優化。大型項目的條件會比一般的項目中更為複雜，就需要從每個環節上面去優化。
怎麼才能更好的運用AOP切面編程
1、不能只單純編碼，還需要打磨代碼
僅僅知道它並不等於會，這是很多工程師可能會面臨的問題，如果只是安裝手冊的案例、項目功能的開發，那確實很簡單。就是從開始寫到結束。就類似數數從一到十。這東西每個人都會
但這樣的結果就是你寫不出好的代碼，本身AOP的編程思想就需要自己從實際開發過程中思考問題後而得出經驗，而不是隻圖完成功能就草草了事。
思想本身就是在簡單的基礎上，進行一步一步的深入挖掘問題，然後再選擇最優方案，一般我們可以分三個步驟來打磨：
第一：先編寫實現業務功能程序代碼
第二：為實現業務功能代碼畫 代碼塊(業務功能編寫會分為很多步驟來實現，像驗證、邏輯處理、調用其他類庫等等) 的流程圖，標註每個業務下的代碼塊 的功能作用、共同點、代碼結構。
第三：抽離重複代碼，重新佈局代碼結構
這樣反饋去打磨，不僅僅可以提升編程思維，你思考問題的方式都會潛移默化的發生改變。
2、借鑑優秀的源碼，化為己用
有的時候想要快速提升編程思維，最簡單直接的方案，就是去閱讀寫好的源代碼，比如像TP5、Laravel這些框架、開源程序的代碼。
例如：中間件、鉤子、日誌、數據庫操作、事務等典型的場景業務和源碼所在的體現
這裡面都是會有AOP的編程思想。先理解別人是如何來編寫的，弄懂別人編寫的代碼費那事，同時裡面用到的一些方法可能大家平時都沒注意的方法。
弄明白後自己可以先基於原理仿寫一下這樣思路的程序，然後再項目中進行實戰的演練使用。在優化其對應的功能。編寫之前可以先把理解後的結構圖作為參照物，這樣可以方便後面的記憶和功能上的拓展。進而化為自己的能力。
3、迴歸本質，考慮不同業務場景需求
有時學習的多了，可能思維都開始固化。這是就需要我們從新的開始根據場景來設計自己的業務。不在受原來編程的思路的影響。
根據對應的業務場景，然後來設計業務中會使用到的業務功能，基於功能實現的步驟，來劃分出可重複使用的業務代碼，再來做到對應功能職責的開發。從新設計的時就會基於現在的思想上面在尋突破點，你的視角在業務場景都會變的不一樣。
綜上所述：AOP編程，是針對傳統業務上面重複使用的代碼進行橫向的拆分後在做到獨立的封裝，然後再提供方法給業務程序進行使用。降低了代碼之間的耦合、增強了業務的拓展性。方便業務內部中的新增或修改等方法的變更。 對於編程思想上面，需要基於借鑑別人優秀的源碼設計思路，和自己總結個人編寫的業務代碼的思路，然後再進行拆解+合併。最終形成個人的設計項目開發的一套體系。為後面的大型項目架構做下思維上面的基礎鋪墊工作。
閱讀更多 蓮花童子哪吒 的文章
