本次主要是聊聊關(guān)于使用接口抽象和降低圈復(fù)雜度的方式
工作中,難免會(huì)遇到老項(xiàng)目老代碼,不僅僅需要我們維護(hù),可能還需要我們?cè)谠瓉?lái)的垃圾代碼上進(jìn)行新增功能或者是進(jìn)行優(yōu)化調(diào)整
例如
現(xiàn)有的老代碼中關(guān)于用戶系統(tǒng)這一塊就已經(jīng)經(jīng)是搖搖欲墜,牽一發(fā)而動(dòng)全身,并且去弄清其中的業(yè)務(wù)細(xì)節(jié),那可以說(shuō)是很難撥開(kāi)迷霧,甚至交接都是一句話的那種,更是難上加難
這種情況,相信每個(gè)公司都會(huì)存在,畢竟過(guò)去的需求,過(guò)去的標(biāo)準(zhǔn),放到現(xiàn)在來(lái)看,啥也不是
若是很多代碼都是面向過(guò)程的,各種業(yè)務(wù)邏輯,非業(yè)務(wù)的邏輯都混合在一起,主流程上插入一些亂七八糟的邏輯,上下文并沒(méi)有啥關(guān)系的東西,一個(gè)函數(shù)上千行的代碼也是隨處可見(jiàn),這種情況狗看了都搖頭
首先咱們編碼前一定會(huì)去捋清楚基本的需求,設(shè)計(jì),以及實(shí)現(xiàn)流程,對(duì)于需要用到的工具我們會(huì)對(duì)代碼結(jié)構(gòu)進(jìn)行分層
例如一些與業(yè)務(wù)主邏輯沒(méi)有什么關(guān)聯(lián)的功能就可以獨(dú)立封裝,便于維護(hù)和使用,例如:
盡可能的將這些單獨(dú)的功能模塊拆解出去,獨(dú)立出來(lái),單獨(dú)維護(hù)
對(duì)于那種沒(méi)有必要同步的功能,完全可以通過(guò)異步化來(lái)進(jìn)行處理,異步的話相信你會(huì)很容易想到消息隊(duì)列來(lái)進(jìn)行實(shí)現(xiàn)
自然實(shí)際項(xiàng)目中你能夠看到最開(kāi)始可能也會(huì)這樣去做,但是隨著業(yè)務(wù)越來(lái)越復(fù)雜,這些獨(dú)立的模塊被各種包進(jìn)行使用,甚至有的開(kāi)始慢慢的弄成定制化的方式
例如
func OpenTenant(){ // 校驗(yàn)基本租戶信息 // 檢查租戶是否特權(quán),完成權(quán)限分配 // 檢查實(shí)際開(kāi)戶的線路,分配各種租戶下的必備賬號(hào) // 完成各種系統(tǒng)的對(duì)接交互 // 進(jìn)行數(shù)據(jù)庫(kù)操作 // 返回結(jié)果}
對(duì)于一個(gè)基本的開(kāi)戶流程,我們或許可以在代碼中看到第一步做什么,第二步又做什么,第三步... ,然而每一個(gè)大步驟下面還有各種小步驟,每一個(gè)小步驟也會(huì)有自己的復(fù)雜邏輯
雖然有了基本的封裝,但是使用的時(shí)候,可能還是會(huì)寫(xiě)到哪,需要啥就去按需定義啥
最終就會(huì)看到一個(gè)函數(shù)上千行,讓你去閱讀和維護(hù),你內(nèi)心能不拒絕嗎嗎?
發(fā)現(xiàn)對(duì)模塊進(jìn)行獨(dú)立封裝還是不太夠,代碼里面太多的冗余代碼,這個(gè)時(shí)候咱們就可以使用接口來(lái)做抽象
使用接口來(lái)做抽象的話,相當(dāng)于是提前考慮好這一類(lèi)的業(yè)務(wù)需要去考慮哪些問(wèn)題,需要注意哪些場(chǎng)景,需要實(shí)現(xiàn)哪一些接口
不同的對(duì)象各自去實(shí)現(xiàn)自己的內(nèi)容就可以了,單獨(dú)去維護(hù)自己的對(duì)象
例如上面的 A 系統(tǒng)的開(kāi)戶流程
// 開(kāi)戶 interface{}type OpenTenant interface{ ValidateTenantInfo(xxx)xxx // 校驗(yàn)基本租戶信息 CheckPrivilege(xxx) xxx // 檢查租戶是否特權(quán),完成權(quán)限分配 CheckLine(xxx) xxx // 檢查實(shí)際開(kāi)戶的線路 ProcessNeccessaryAccount(xxx) xxx //分配各種租戶下的必備賬號(hào) ProcessNoticeMsg(xxx) xxx// 完成各種系統(tǒng)的對(duì)接交互 AddTenant(xxx) xxx// 進(jìn)行數(shù)據(jù)庫(kù)操作}
這僅僅是一個(gè) demo,對(duì)于一個(gè)開(kāi)戶 interface{} 來(lái)說(shuō),A 系統(tǒng)可以去實(shí)現(xiàn),B 系統(tǒng)仍然也可以去實(shí)現(xiàn),各自完成自己的內(nèi)容,例如這樣
圖片
對(duì)于優(yōu)化代碼的話,我們就可以將上述的一些實(shí)現(xiàn)步驟,放到這個(gè)接口中來(lái)即可
咱們定義接口,更多的是去規(guī)范流程和便于維護(hù),這樣還可以讓我們的程序往高內(nèi)聚低耦合方面去靠,不同的對(duì)象之間,完全是安全的,自己玩自己的一套,只不過(guò)遵循的規(guī)范是一樣的的
圈復(fù)雜度也可以理解為條件復(fù)雜度,是一種用來(lái)衡量代碼復(fù)雜度的標(biāo)準(zhǔn)
例如一些沒(méi)有判斷語(yǔ)句的代碼,圈復(fù)雜度就是 1
如果是 if...else 那么圈復(fù)雜度就是 2 ,簡(jiǎn)單的就可以理解為涉及到判斷條件的數(shù)量,那么就 +1
例如有這樣的代碼
func testDemo() { var op OpenTenant switch TenantType { case A: op = a.New() case B: op = b.New() case C: op = c.New() default: ... } op.ValidateTenantInfo()....}
那么就如上demo ,來(lái)看,圈復(fù)雜度就是 4 ,其中有 3 個(gè)判斷條件和一個(gè)默認(rèn)的正常順序,因此是 3 +1 = 4
這個(gè)時(shí)候,我們可以如何降低圈復(fù)雜度呢?
我們完全就可以使用表格的方式,訪問(wèn)數(shù)據(jù)直接訪問(wèn)表格就可以了,盡可能的減少這些判斷條件,例如我們就可以這樣來(lái)寫(xiě)
var openTenantMap = map[string]openTenantObject{ A: a.New(), B: b.New(), C: c.New(),}func testDemo(){ op := openTenantMap[TenantType ] ... op.ValidateTenantInfo() ...}
這種方式,是不是就可以將圈復(fù)雜度降低到 1 了呢?而且看起來(lái)也優(yōu)雅了很多
主要叮囑了我們維護(hù)和開(kāi)發(fā)的時(shí)候,要重視封裝,重視抽象,重視降低圈復(fù)雜度
只要你用心去打磨,自然會(huì)變得越來(lái)越好
但是可別生搬硬套,畢竟一些定制化的需求,定制化的代碼你去做接口抽象是沒(méi)有啥意義的,一起加油吧,xdm
至此,本次就是這樣,希望能夠給你帶來(lái)一丁點(diǎn)幫助
朋友們,你的支持和鼓勵(lì),是我堅(jiān)持分享,提高質(zhì)量的動(dòng)力
技術(shù)是開(kāi)放的,我們的心態(tài),更應(yīng)是開(kāi)放的。擁抱變化,向陽(yáng)而生,努力向前行。
本文鏈接:http://www.tebozhan.com/showinfo-26-12129-0.htmlGO 中優(yōu)雅編碼和降低圈復(fù)雜度
聲明:本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí),若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除處理。郵件:2376512515@qq.com