老代碼多=過度耦合=if else？阿里巴巴工程師這樣捋直老代碼

1、老代碼多=過度耦合=if else？阿里巴巴工程師這樣捋直老代碼簡介 在業(yè)務(wù)開發(fā)的過程中，往往存在平臺(tái)代碼和業(yè)務(wù)代碼耦合嚴(yán)峻難以分別、業(yè)務(wù)和業(yè)務(wù)之間代碼交織缺少拆解的現(xiàn)象。平臺(tái)和業(yè)務(wù)代碼交織導(dǎo)致不易修改，不同業(yè)務(wù)的代碼交織增強(qiáng)了不同負(fù)責(zé)團(tuán)隊(duì)之間的協(xié)同成本。因此不論從代碼質(zhì)量，還是從團(tuán)隊(duì)配合的角度來看都嚴(yán)峻地影響了開發(fā)團(tuán)隊(duì)之間的協(xié)同效率和開發(fā)效率，終于影響到了用戶體驗(yàn)和業(yè)務(wù)進(jìn)展。在閑魚，商品發(fā)布和編輯功能也是如此。本文將以閑魚商品發(fā)布和編輯功能的改造為例，向大家展示閑魚是如何解決此類問題，從而更有效地協(xié)同更多團(tuán)隊(duì)更快更穩(wěn)定地支撐各種業(yè)務(wù)的。 發(fā)布編輯功能的升級改造 為了實(shí)現(xiàn)上述目標(biāo)，針對發(fā)布和編

2、輯功能，舉行了兩輪升級。第一輪的目標(biāo)在于平臺(tái)和業(yè)務(wù)分別、業(yè)務(wù)和業(yè)務(wù)隔離；而其次輪將更進(jìn)一步，目標(biāo)在于系統(tǒng)之間的解耦合，提升團(tuán)隊(duì)協(xié)同效率。 1.平臺(tái)和業(yè)務(wù)分別，業(yè)務(wù)和業(yè)務(wù)隔離 第一輪改造中，閑魚將原先的商品發(fā)布和編輯功能從老應(yīng)用中抽取到了新應(yīng)用item。為了實(shí)現(xiàn)平臺(tái)和業(yè)務(wù)分別、業(yè)務(wù)和業(yè)務(wù)隔離的目標(biāo)，閑魚自研了一套技術(shù)框架swak，詳細(xì)請參考文章業(yè)務(wù)代碼解構(gòu)利器-swak，該文介紹了其設(shè)計(jì)思想和實(shí)現(xiàn)原理。接入swak框架后，平臺(tái)規(guī)律和業(yè)務(wù)規(guī)律得到了分別，各個(gè)業(yè)務(wù)（如租房業(yè)務(wù)、免費(fèi)送業(yè)務(wù)）之間的規(guī)律也不再耦合，而是變成package隔離（固然也是可以做成jar包隔離）。 看一看改造后的應(yīng)用狀況暗示圖

3、： 我們按照發(fā)布和編輯的主干流程，抽象了17個(gè)swak擴(kuò)展點(diǎn)。 發(fā)布和編輯的主干流程主要就是對這些擴(kuò)展點(diǎn)的編排。主干流程的編寫并不需要考慮業(yè)務(wù)上怎么實(shí)現(xiàn)這些擴(kuò)展點(diǎn)的。 我們按照不同的業(yè)務(wù)（在swak里面更精確的表述是tag）對這些擴(kuò)展點(diǎn)舉行了各自的實(shí)現(xiàn)。 按照這樣的開發(fā)方式，我們可以把開發(fā)學(xué)生分成如下的兩種角色： 各業(yè)務(wù)開發(fā)人員。各業(yè)務(wù)開發(fā)人員主要是負(fù)責(zé)各個(gè)業(yè)務(wù)相關(guān)的代碼。在item應(yīng)用里面，業(yè)務(wù)學(xué)生需要維護(hù)其業(yè)務(wù)中和發(fā)布編輯相關(guān)的共性化業(yè)務(wù)規(guī)律。 主干開發(fā)人員。主干的人員只需要維護(hù)主干的代碼，尤其是擴(kuò)展點(diǎn)的抽象。隨著不同業(yè)務(wù)的不斷接入，原先的擴(kuò)展點(diǎn)也需要隨之調(diào)節(jié)。 如在之前的業(yè)務(wù)代碼解構(gòu)利器

4、-swak一文中指出的一樣，經(jīng)過swak改造后，獲得了如下的幾個(gè)優(yōu)點(diǎn)： 代碼規(guī)律清楚，可變和不行變一目了然。 代碼復(fù)用度變高。 可變規(guī)律根據(jù)標(biāo)簽舉行隔離，單個(gè)標(biāo)簽的實(shí)現(xiàn)不會(huì)影響到其他標(biāo)簽的實(shí)現(xiàn)，降低開發(fā)和測試成本。無論是根據(jù)類型分還是根據(jù)類目分，對應(yīng)的開發(fā)和測試學(xué)生只需要關(guān)注對應(yīng)的規(guī)律即可。 新接手的開發(fā)人員能夠迅速理解，輕松上手。 2.系統(tǒng)之間的解耦合，提升團(tuán)隊(duì)協(xié)同效率 以租房為例——租房業(yè)務(wù)的學(xué)生需要在item應(yīng)用中維護(hù)一套租房發(fā)布編輯相關(guān)的規(guī)律（如校驗(yàn)地小區(qū)數(shù)據(jù)、地鐵數(shù)據(jù)真切性等）；租房業(yè)務(wù)的學(xué)生還需要在細(xì)節(jié)應(yīng)用的規(guī)律中維護(hù)一套和租房細(xì)節(jié)相關(guān)的規(guī)律

5、（如展示地圖，展示內(nèi)部設(shè)施標(biāo)簽）；租房業(yè)務(wù)的學(xué)生還需要在交易應(yīng)用的規(guī)律中維護(hù)一套和租房交易相關(guān)的規(guī)律（如預(yù)約看房）等等。租房的學(xué)生不僅僅需要著手于自己的代碼規(guī)律，還需要修改發(fā)布和編輯應(yīng)用item、還需要修改細(xì)節(jié)應(yīng)用，還需要修改交易應(yīng)用這種體驗(yàn)是十分糟糕的，有極大的可能性接手一個(gè)容易業(yè)務(wù)就需要修改和發(fā)布四五個(gè)應(yīng)用。 另一方面，從主干開發(fā)人員的角度來說，其應(yīng)用不僅僅由自己或自己的小團(tuán)隊(duì)來維護(hù)，還有無數(shù)業(yè)務(wù)開發(fā)人員也在修改和發(fā)布此應(yīng)用，且頻率會(huì)遠(yuǎn)遠(yuǎn)超過主干開發(fā)任務(wù)的發(fā)布和部署頻次（否則就是主干擴(kuò)展點(diǎn)規(guī)律抽取得不好了）。這不利于囫圇應(yīng)用的穩(wěn)定性。a業(yè)務(wù)服務(wù)掛了，應(yīng)當(dāng)只影響a業(yè)務(wù)，而不應(yīng)當(dāng)影響主干。依此

6、規(guī)律，最好能做到j(luò)vm隔離。本質(zhì)上來說，第一輪改造完成了業(yè)務(wù)之間的解耦合，而其次輪則是系統(tǒng)之間的解耦合。 康威定律告知我們： any organization that designs a system （defined more broadly here than just information systems） will inevitably produce a design whose structure is a copy of the organization&39;s communication structure. 簡而言之就是人員組織結(jié)構(gòu)和系統(tǒng)結(jié)構(gòu)之間的全都性。而完成

7、系統(tǒng)之間的解耦合又恰恰是符合康威定律的。這一輪的改造，我們稱之為業(yè)務(wù)服務(wù)化。 業(yè)務(wù)服務(wù)化改造計(jì)劃 首先，我們把租房業(yè)務(wù)給單獨(dú)抽取出來。原先的帖子和拍賣業(yè)務(wù)臨時(shí)沒有自立的團(tuán)隊(duì)來予以維護(hù)（但也基本上沒有什么新需求）因此臨時(shí)仍然放在主干應(yīng)用中，時(shí)機(jī)合適將會(huì)和租房應(yīng)用一樣遷移出去。 第二，租房業(yè)務(wù)通過遠(yuǎn)程服務(wù)的方式給主干應(yīng)用提供服務(wù)。接口即是主干業(yè)務(wù)的提供的擴(kuò)展點(diǎn)。因?yàn)楝F(xiàn)在是優(yōu)先用法遠(yuǎn)程服務(wù)來銜接主干應(yīng)用和垂直應(yīng)用，考慮到性能問題和平安問題，我們在擴(kuò)展點(diǎn)的定義上也做了一些特別的改動(dòng)，后文會(huì)有針對性的詳述。 最后，swak框架做了一些轉(zhuǎn)變以注冊和調(diào)用遠(yuǎn)程服務(wù)。相對于本地服務(wù)，遠(yuǎn)程服務(wù)普通都是有超時(shí)、銜接

8、異樣等問題。然而不同接口對于這些異樣狀況其處理策略也是迥然不同的，后文swak框架的針對性改進(jìn)會(huì)詳述這些改動(dòng)。 通過這種方式，我們將主干應(yīng)用和各業(yè)務(wù)應(yīng)用徹底分別了。仍然以租房業(yè)務(wù)為例，租房團(tuán)隊(duì)負(fù)責(zé)開發(fā)和維護(hù)租房業(yè)務(wù)的自立應(yīng)用rent。租房共性化的發(fā)布和編輯需求只需要開發(fā)和部署rent應(yīng)用，而不必修改主干應(yīng)用。主干應(yīng)用只由主干團(tuán)隊(duì)的學(xué)生負(fù)責(zé)維護(hù)，不會(huì)被其他業(yè)務(wù)團(tuán)隊(duì)的學(xué)生所開發(fā)和部署，穩(wěn)定性越發(fā)能得以保障。各業(yè)務(wù)系統(tǒng)自立開發(fā)、自立部署。這些都大幅地削減了不須要的交流成本、提升協(xié)同效率。 主干應(yīng)用和業(yè)務(wù)應(yīng)用是通過薄薄的一層接口所聯(lián)系起來的，這層薄薄的接口都是聲明：interface定義、do的定義和

9、擴(kuò)展點(diǎn)的默認(rèn)reduce策略定義。 swak框架的針對性改進(jìn) 在之前的業(yè)務(wù)代碼解構(gòu)利器-swak一文中指出了，swak框架在應(yīng)用啟動(dòng)的時(shí)候會(huì)通過各種注冊器（registery）注冊框架所需的信息。其中最重要的信息就是——業(yè)務(wù)tag及其對應(yīng)的swak接口的實(shí)現(xiàn)類類名或者類實(shí)例instance。大多rpc框架都會(huì)在client端提供一個(gè)代理，代理掉內(nèi)部的服務(wù)發(fā)覺、保活、序列化、網(wǎng)絡(luò)通信、反序列化等一系列操作。事實(shí)上，swak為了支持遠(yuǎn)程服務(wù)調(diào)用，只需要將業(yè)務(wù)tag，以及這些rpc的client的instance的對應(yīng)關(guān)系注冊進(jìn)去就可以了。在閑魚，rpc用法的

10、是阿里通用的hsf框架（其類似的一個(gè)開源框架是dubbo），這里的rpc的client就是hsf中的consumerbean。 上文還提到了rpc調(diào)用會(huì)引入服務(wù)超時(shí)、銜接異樣的概念。為何要限制超時(shí)？是由于不能被單個(gè)應(yīng)用的超時(shí)占領(lǐng)了主干應(yīng)用的服務(wù)資源而引起其他服務(wù)和囫圇應(yīng)用系統(tǒng)受到影響（如大多數(shù)線程堵塞在超時(shí)調(diào)用上）。無論是超時(shí)異樣還是銜接異樣，在業(yè)務(wù)上也有對應(yīng)的處理策略。在這里，我們定義了三種異樣處理策略，通過在配置上設(shè)置相應(yīng)的注解，swak框架會(huì)自動(dòng)根據(jù)策略來處理異樣。這三種策略是： ignore。 即，挺直向上層拋出異樣。 skip。對于一個(gè)接口有多個(gè)tag執(zhí)行的時(shí)候，本tag下該擴(kuò)展點(diǎn)將

11、跳過，繼續(xù)執(zhí)行其他tag下該擴(kuò)展點(diǎn)的實(shí)現(xiàn)。 default_value。返回默認(rèn)值。默認(rèn)值通過spel表達(dá)式舉行設(shè)置。 削減擴(kuò)展點(diǎn)數(shù)量 盡人皆知，rpc調(diào)用相對于本地調(diào)用會(huì)增強(qiáng)一部分的網(wǎng)絡(luò)傳輸和序列化開銷。對于單次調(diào)用來說，增強(qiáng)若干ms并沒有什么問題，但對于調(diào)用10次、20次或更多，這筆開銷就相當(dāng)可觀而應(yīng)當(dāng)引起重視了。為此，如何降低rpc開銷，是一個(gè)必需要考慮的問題。 最牢靠的辦法就是降低rpc的次數(shù)。 在實(shí)踐中我們發(fā)覺，無數(shù)擴(kuò)展點(diǎn)事實(shí)上都是獵取業(yè)務(wù)配置。如在閑魚業(yè)務(wù)中，是否支持多庫存就是一種配置，如租房不支持多庫存。這些業(yè)務(wù)配置項(xiàng)是由其業(yè)務(wù)形態(tài)所打算的，基本不會(huì)變動(dòng)。因此可以將一組配置項(xiàng)打包

12、一起調(diào)用，并且可以緩存下來，也可以挺直由主干應(yīng)用舉行維護(hù)。在item應(yīng)用里，這些配置項(xiàng)關(guān)系到主干的通用存儲(chǔ)過程，目前由各業(yè)務(wù)方托付主干開發(fā)人員舉行維護(hù)，目前配置在主干環(huán)境。可以通過阿里的動(dòng)態(tài)配置平臺(tái)（如switch、diamond）舉行動(dòng)態(tài)修改。 另外我們對部分鄰接的擴(kuò)展點(diǎn)舉行了合并。這些相鄰擴(kuò)展點(diǎn)之間的規(guī)律比較容易，且不會(huì)中斷主流程。通過配置型接口和鄰接擴(kuò)展點(diǎn)合并這兩種操作，我們將擴(kuò)展點(diǎn)數(shù)量降低由17個(gè)降低到了6個(gè)。要注重的是，擴(kuò)展點(diǎn)并不是越少越好。擴(kuò)展點(diǎn)越少，越意味著過度擬合，可能會(huì)對后續(xù)業(yè)務(wù)變更無法適應(yīng)導(dǎo)致主干需要大幅改動(dòng)，因此需要在數(shù)量和擴(kuò)展性之間找到一個(gè)平衡。 另外值得一提的是，sw

13、ak為配置型擴(kuò)展點(diǎn)做了相應(yīng)的小改造，并提供了查看當(dāng)前配置型擴(kuò)展點(diǎn)返回值的可視化界面。開發(fā)人員可以直觀地了解當(dāng)前各個(gè)業(yè)務(wù)的配置值。 接口對象定義和詳情設(shè)計(jì) 在閑魚，各種業(yè)務(wù)所需要存儲(chǔ)的東西大同小異，從閑魚的發(fā)布界面上來看就不難發(fā)覺這一點(diǎn)，都是在基礎(chǔ)對象（如標(biāo)題、描述、）之外添加一些業(yè)務(wù)相關(guān)的數(shù)據(jù)，如拍賣業(yè)務(wù)中指定拍賣的開拍時(shí)光等信息，免費(fèi)送業(yè)務(wù)中設(shè)置兌換幣值，圖書業(yè)務(wù)上設(shè)置條形碼。即對一本圖書舉行拍賣固然也是允許的，這就浮現(xiàn)了拍賣業(yè)務(wù)和圖書業(yè)務(wù)疊加起來的復(fù)合型業(yè)務(wù)。 對于主干應(yīng)用開發(fā)人員來說，應(yīng)當(dāng)提供單個(gè)接口以支持全部業(yè)務(wù)類型，這樣不用每次修改或者新增業(yè)務(wù)時(shí)都需要提供新接口。從穩(wěn)定性的角度考慮，

14、這樣的要求很合理。既然是單個(gè)接口，那么do的定義也應(yīng)當(dāng)統(tǒng)一。以商品do為例，有以下三種方式： 第一種是繼承型結(jié)構(gòu)，該結(jié)構(gòu)不適用于業(yè)務(wù)疊加的狀況。另外主干需要知曉各個(gè)業(yè)務(wù)的do，每次業(yè)務(wù)修改或新增，主干都需要做變動(dòng)。 其次種是組合型結(jié)構(gòu)，適用于業(yè)務(wù)疊加的狀況，但同上一種一樣，主干需要知曉各個(gè)業(yè)務(wù)的do，每次業(yè)務(wù)修改或新增，主干也需要隨之變動(dòng)。 第三種用法了map類型類承載各個(gè)業(yè)務(wù)（biz）的定義類型。主干徹低不知道、也不需要知道各個(gè)業(yè)務(wù)do是如何組成的。這種方式具有最好的擴(kuò)展性（有點(diǎn)無邊界的擴(kuò)展），也分別了主干應(yīng)用和業(yè)務(wù)應(yīng)用，最臨近主干和業(yè)務(wù)分別的期望。終于我們挑選了這一種。 用法第三種的對象模

15、型，以新加一種業(yè)務(wù)為例，其開發(fā)流程是： 新業(yè)務(wù)服務(wù)端開發(fā)人員和客戶端開發(fā)人員商定各業(yè)務(wù)的do，這些do會(huì)存儲(chǔ)到bizmap字段。主干應(yīng)用開發(fā)人員不需要了解這些商定。 主干應(yīng)用新增一份新業(yè)務(wù)的配置，事實(shí)上是新業(yè)務(wù)的識(shí)別信息和路由信息。 新業(yè)務(wù)應(yīng)用實(shí)現(xiàn)主干擴(kuò)展點(diǎn)。 聯(lián)調(diào)、測試和上線。 業(yè)務(wù)應(yīng)用在擴(kuò)展點(diǎn)返回值中設(shè)置需要更新的數(shù)據(jù)，由主干應(yīng)用合并。業(yè)務(wù)應(yīng)用不應(yīng)當(dāng)也不行以挺直修改itemdo，避開影響其他業(yè)務(wù)的處理規(guī)律。對于發(fā)布和編輯這種需要持久化存儲(chǔ)的規(guī)律來說，必需要強(qiáng)控各業(yè)務(wù)對itemdo的修改，否則理論上來說，各業(yè)務(wù)都有可能將全部的關(guān)鍵字段修改得面目全非。前面提到的配置型接口中，就有這樣的配置——該業(yè)務(wù)是否可以修改屬性字段、該業(yè)務(wù)是否可以修改描述字段等配