在一個(gè)充滿活力的軟件開(kāi)發(fā)團(tuán)隊(duì)中，新成員小張剛剛加入不久。他對(duì)于團(tuán)隊(duì)正在使用的復(fù)雜系統(tǒng)還不是很熟悉，但面對(duì)緊迫的項(xiàng)目進(jìn)度和上級(jí)施加的壓力，他急于證明自己，并希望能盡快為團(tuán)隊(duì)做出貢獻(xiàn)。團(tuán)隊(duì)正計(jì)劃上線一個(gè)新的特性，這個(gè)特性需要在不干擾系統(tǒng)其他部分的前提下實(shí)現(xiàn)。

小張?jiān)跒g覽了系統(tǒng)的代碼庫(kù)后，發(fā)現(xiàn)要全面理解并調(diào)整整個(gè)系統(tǒng)設(shè)計(jì)以適應(yīng)新的特性，需要花費(fèi)大量的時(shí)間和精力。他深知自己作為新人，在這方面還有所欠缺，因此，他決定采取一個(gè)他認(rèn)為更為“高效”的方法：在某個(gè)關(guān)鍵位置添加一個(gè)臨時(shí)的標(biāo)志位（flag），然后在所有需要改動(dòng)的地方都加上if判斷，以確保新特性能夠按時(shí)上線，同時(shí)盡量減少對(duì)現(xiàn)有系統(tǒng)的影響。

雖然這種方法在短時(shí)間內(nèi)確實(shí)讓新特性得以順利上線，但團(tuán)隊(duì)中的資深成員很快便發(fā)現(xiàn)了潛在的問(wèn)題。這種做法雖然看似快速解決了問(wèn)題，但實(shí)際上卻在系統(tǒng)中埋下了隱患。它不僅增加了代碼的復(fù)雜性，降低了代碼的可讀性和可維護(hù)性，還可能在未來(lái)引發(fā)更多的bug和性能問(wèn)題。更重要的是，這種做法違背了軟件開(kāi)發(fā)中的最佳實(shí)踐，即應(yīng)通過(guò)優(yōu)化系統(tǒng)設(shè)計(jì)來(lái)適應(yīng)新的問(wèn)題空間，而不是通過(guò)添加臨時(shí)性的補(bǔ)丁來(lái)解決問(wèn)題。

“幾乎每個(gè)軟件開(kāi)發(fā)組織都有至少一個(gè)將戰(zhàn)術(shù)編程發(fā)揮到極致的開(kāi)發(fā)人員：戰(zhàn)術(shù)龍卷風(fēng)”，而且常常被視為團(tuán)隊(duì)”英雄“，因?yàn)槟堋翱焖偻瓿扇蝿?wù)且高產(chǎn)”。

“戰(zhàn)術(shù)龍卷風(fēng)”通常以戰(zhàn)術(shù)編程為主要手段，即采用最快速、最直接的方法來(lái)解決當(dāng)前的問(wèn)題，而不考慮長(zhǎng)遠(yuǎn)的影響和代碼的可持續(xù)性。這種方法在初次使用時(shí)往往能夠取得顯著的效果，任務(wù)完成得既快又好，贏得了團(tuán)隊(duì)成員的贊譽(yù)和領(lǐng)導(dǎo)的認(rèn)可。

然而，隨著時(shí)間的推移，“戰(zhàn)術(shù)龍卷風(fēng)”所留下的隱患逐漸暴露出來(lái)。由于缺乏對(duì)系統(tǒng)設(shè)計(jì)的深入理解和長(zhǎng)遠(yuǎn)規(guī)劃，他的代碼往往難以維護(hù)和擴(kuò)展。當(dāng)需要添加新功能或修復(fù)bug時(shí)，團(tuán)隊(duì)成員往往需要花費(fèi)更多的時(shí)間和精力來(lái)理解和修改他的代碼。因此，第二次和第三次修改時(shí)，效率會(huì)大幅下降，甚至可能引發(fā)新的問(wèn)題。

實(shí)際造成結(jié)果：第一次快、第二次慢、第三次更慢。

代碼：簡(jiǎn)潔與優(yōu)雅的雙重追求

我們做業(yè)務(wù)開(kāi)發(fā)，代碼的優(yōu)雅簡(jiǎn)潔，不能局限在一段方法，還是要從整個(gè)工程結(jié)構(gòu)然后在到類、到方法，這樣從宏觀到中觀再到微觀的整體去要求。我們的應(yīng)用工程結(jié)構(gòu)，常見(jiàn)大致分為四層。分別是api層、biz層、domain層和dao層。

這個(gè)時(shí)候我們就要很清晰地熟悉每一層的職責(zé)，然后將我們的代碼放入進(jìn)去。首先，api層的作用，正如它的名字一樣，是提供api服務(wù)的。向誰(shuí)提供api呢，比如客戶端，比如APP端、pc端等等，公司外面的客戶，比如isv等。其次，biz層的作用，這一層也叫業(yè)務(wù)服務(wù)層。它主要負(fù)責(zé)編排。把一個(gè)業(yè)務(wù)場(chǎng)景下的主流程邏輯處理完成。這個(gè)主流程會(huì)涉及到多個(gè)原子接口，就在這層負(fù)責(zé)組裝。再次，domain層的作用，也叫做領(lǐng)域服務(wù)層。按照OO思想，領(lǐng)域編程的思維，我們的”厚對(duì)象“的代碼都在這層。比如訂單域、運(yùn)費(fèi)域等。這里對(duì)“這一層的位置”多說(shuō)幾句，在沒(méi)有形成領(lǐng)域之前，這層一般叫service層，不過(guò)我們都是建議領(lǐng)域思維編寫(xiě)代碼。最后是dao層，也就是我們的存儲(chǔ)層了，負(fù)責(zé)持久化。

在清晰了每一層的作用之后，如果我們的代碼職責(zé)也是按照這樣逐層放入的，那么大體是符合我們的整潔要求的。但是呢，隨著時(shí)間的推移，需求的增多和變化。原來(lái)整潔的工程結(jié)構(gòu)和代碼已經(jīng)不那么優(yōu)雅了。

這個(gè)時(shí)候，一般會(huì)出現(xiàn)兩類現(xiàn)象，一類是業(yè)務(wù)層（biz）變的臃腫，能力層（domain）變的單薄。另一類是出現(xiàn)了網(wǎng)狀調(diào)用。而且這兩類現(xiàn)象也很有可能是混合在一起出現(xiàn)。

這兩類現(xiàn)象會(huì)直接帶來(lái)下面4種結(jié)果。

1、biz層越來(lái)越”胖“。胖了之后，還長(zhǎng)成了兩小層。上小層是面向單一業(yè)務(wù)場(chǎng)景的“業(yè)務(wù)biz層”，下小層成了通用場(chǎng)景可復(fù)用的“通用biz層”。

2、service層越來(lái)越”瘦“。當(dāng)service層變薄了以后，也就只能淪為service了，而這樣的service層跟dao層實(shí)際沒(méi)什么區(qū)別，更不能再稱之為domain層或者沒(méi)有機(jī)會(huì)演變成domain層。

3、但是也不是所有的service層都變瘦、變薄了?？赡苡械奈s，有的膨脹。人員與設(shè)計(jì)的差異，導(dǎo)致顆粒度不一。

4、出現(xiàn)了網(wǎng)狀調(diào)用。原本biz-1 -> service-1 的實(shí)現(xiàn)鏈路下，隨著新增業(yè)務(wù)邏輯，又新起了一個(gè)service-2，鏈路演變成了biz-1 -> service-1-> service-2。“這樣的趨勢(shì)持續(xù)發(fā)展下去，會(huì)發(fā)現(xiàn)biz-1下的service調(diào)用鏈路越發(fā)的復(fù)雜，呈現(xiàn)為一顆深度調(diào)用樹(shù)，而biz層失去了業(yè)務(wù)編排的作用退化為一個(gè)業(yè)務(wù)場(chǎng)景入口的標(biāo)志符”。有可能后面繼續(xù)3-4-5-6，越挖越深，不見(jiàn)盡頭。

很顯然，到這里，這樣的結(jié)構(gòu)現(xiàn)狀，代碼現(xiàn)狀，已經(jīng)遠(yuǎn)離了我們簡(jiǎn)潔和優(yōu)雅的初衷。也談不上提效了。

到此，我們介紹了架構(gòu)提效中的穩(wěn)定、性能和代碼這三個(gè)主要的方面，限于篇幅和架構(gòu)本身的實(shí)踐性，還需要我們?cè)诩軜?gòu)提效上進(jìn)行持續(xù)的優(yōu)化。需要我們?cè)诜€(wěn)定、性能、代碼三大維度上不斷探索和實(shí)踐。通過(guò)高可用架構(gòu)設(shè)計(jì)、性能優(yōu)化策略、模塊化與解耦、代碼質(zhì)量與規(guī)范等措施，我們可以構(gòu)建一個(gè)既穩(wěn)定又高效，且易于維護(hù)和擴(kuò)展的系統(tǒng)。

“在復(fù)雜的事物發(fā)展過(guò)程中，有許多的矛盾存在，其中必有一種是主要的矛盾，由于它的存在和發(fā)展規(guī)定和影響著其他矛盾的存在和發(fā)展。”

架構(gòu)的發(fā)展本身也是對(duì)抗熵增這一矛盾的過(guò)程，我們上面描述的穩(wěn)定、性能和代碼中的矛盾方面有是圍繞和關(guān)聯(lián)這一主要矛盾的。在這個(gè)過(guò)程中不僅有系統(tǒng)的有序變無(wú)序，也有組織的簡(jiǎn)單變復(fù)雜。我們既要關(guān)注技術(shù)層面的提升，更要注重團(tuán)隊(duì)協(xié)作、知識(shí)共享和持續(xù)改進(jìn)的文化建設(shè)。只有這樣，我們才能在快速變化的市場(chǎng)環(huán)境中，保持競(jìng)爭(zhēng)力，不斷前行。

最后，如果您對(duì)文章中的表述和觀點(diǎn)有任何問(wèn)題，亦或者您當(dāng)前也正在致力于架構(gòu)提效方面的工作，我們可以一起學(xué)習(xí)交流，微信號(hào)：wangxindong2015。

REF：
1、https://time.geekbang.org/column/article/167844 如何判斷架構(gòu)設(shè)計(jì)的優(yōu)劣
2、https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ 軟件設(shè)計(jì)的哲學(xué)
3、https://mp.weixin.qq.com/s/jJzzJIGozOpt7KaXwBS3Ww 業(yè)務(wù)系統(tǒng)架構(gòu)實(shí)踐總結(jié)
4、《矛盾論》


審核編輯 黃宇