3 根因分析

接下來分析下為什么會產(chǎn)生代碼差的原因，這個問題有外部原因，也有內(nèi)部原因。外部原因主要有：項目排期急，沒有多少時間去設(shè)計；資源短缺，人手不夠，只能怎么快怎么來；緊急問題修復(fù)，臨時方案快速處理……。內(nèi)部原因主要有：自身技能低，怎么技能沒有掌握到，如Lamda表達式、常用的工具類、框架高級用法等；無極致追求的精神，僅僅完成需求就行，穩(wěn)定性、可擴展性、性能、數(shù)據(jù)一致性等沒有考慮……

筆者認為最為關(guān)鍵的是內(nèi)部自身的問題，根因就兩個：自我要求不高；無反饋通道。如果對自已要求不高，僅僅滿足完成需求開發(fā)就止步了，很難寫出高質(zhì)量的代碼，另外如果沒有外部反饋，也難以提高自己的技能。筆者之前的主管非常嚴厲，對大家寫的代碼review比較仔細，一個變量名、一段邏輯的寫法，反復(fù)讓修改，這其實是提升技能最快的方法。

二 提升代碼質(zhì)量的方法

提升代碼質(zhì)量的方法，筆者喜歡用三個方法：領(lǐng)域建模、設(shè)計原則、設(shè)計模式，主要談下如何使用。

三 領(lǐng)域模型的作用

領(lǐng)域建模的入門門檻比較高，包含了一些難理解的概念。本篇文章中并不會講述如何進行建模（可以私下交流），筆者發(fā)現(xiàn)讓大家接受領(lǐng)域建模遠比知道如何建模更重要，當(dāng)你知道了領(lǐng)域建模的作用后，自己會想各種辦法去學(xué)習(xí)。下面通過筆者經(jīng)歷的一些實際案例進行闡述，讓大家聽起來并不感覺到那么空洞。

1 簡化認識

筆者工作一年后加入到了一家金融公司，當(dāng)時對金融一無所知，開始接觸到標的、債權(quán)、債權(quán)轉(zhuǎn)讓、融資擔(dān)保、非融資擔(dān)保等名詞后，一時感到無所適從，每天要學(xué)習(xí)非常多的新內(nèi)容。

兩個月后，我的主管給我們做了一次分享，就拿了一張ppt來講，它里面包含了領(lǐng)域的實體，以及實體之間的關(guān)聯(lián)關(guān)系，一下子我就知道了整個業(yè)務(wù)是怎么玩轉(zhuǎn)的。模型的作用就是簡化人對事物的認識，如果一開始我們就陷入到代碼細節(jié)中，很難看到業(yè)務(wù)的全貌，而且代碼是為了實現(xiàn)業(yè)務(wù)能力，當(dāng)你知道了業(yè)務(wù)之后，再去看代碼就會快得多。

2 統(tǒng)一認識

在公司里，有研發(fā)、產(chǎn)品、運營、測試……，當(dāng)我們在一起交流的時候，大家默認的語言是不統(tǒng)一的，開發(fā)經(jīng)常講怎么操作這張數(shù)據(jù)庫表，產(chǎn)品經(jīng)常講業(yè)務(wù)模式……這就導(dǎo)致大家的認識并不統(tǒng)一。

那是一個晚上，剛和交互同學(xué)確認完交互流程后，突然她問了一個問題：把相似的頁面讓賣家移到同一個文夾中，這個好實現(xiàn)吧？聽完后告知不能，交互同學(xué)一聽說這很合理呀，怎么實現(xiàn)不了？開始給她講了下現(xiàn)有的系統(tǒng)流程，發(fā)現(xiàn)她聽得一臉懵逼，馬上發(fā)現(xiàn)問題了，我是用開發(fā)的語言在描述問題，立馬換了一種方式，找了一支筆和一張紙，給交互同學(xué)畫了我們的領(lǐng)域模型是什么，業(yè)務(wù)實體之間的交互是怎樣的，一講完后，交互同學(xué)馬上明白了為什么不能實現(xiàn)的原因所在了。

3 指導(dǎo)設(shè)計

有的同學(xué)覺得領(lǐng)域建模偏空洞，比較虛，其實除了能夠簡化認識和統(tǒng)一認識外，領(lǐng)域建模還可能指導(dǎo)代碼設(shè)計，比如上面舉的店鋪導(dǎo)航Tab的例子，筆者就是通過領(lǐng)域建模來設(shè)計的，雖然它是一個小的需求，并不妨礙領(lǐng)域建模的運用。在下圖中，可以清晰的看到，導(dǎo)航欄包含了若干個Tab，一個Tab包含規(guī)格信息和點擊操作信息。把這個業(yè)務(wù)模式畫出來之后，對應(yīng)的代碼中也會有上面的概念，現(xiàn)實與代碼之間存在映射關(guān)系，模型即代碼，代碼即模型。如果你的模型不能反映現(xiàn)實，模塊只能算是一個花架子，范鋼老師對此總結(jié)了三句話：現(xiàn)實有什么事物，對應(yīng)有什么對象；現(xiàn)實事物有什么行為，對應(yīng)對象有什么方法；現(xiàn)實事物有什么聯(lián)系，對應(yīng)對象有什么關(guān)聯(lián)。

四 設(shè)計原則的底層邏輯

1 SOLID

對于設(shè)計原則，一般我們會談到SOLID，它包含了五個設(shè)計原則：

2 為什么要有設(shè)計原則

我們對SOLID原則基本上聽說過或者了解過，但為什么要有這些設(shè)計原則呢？為了回答這個問題，我們從目標往下推導(dǎo)下。軟件開發(fā)的目標是高內(nèi)聚、低耦合，這句掛在嘴邊的話，發(fā)現(xiàn)很難衡量，比如要回答：什么樣的叫高內(nèi)聚？什么樣的叫低耦合？高內(nèi)聚要高到什么程度？低耦合要低到什么程度？這四個問題并不太好回答。

反過來想想，如果我們的代碼不是高內(nèi)聚和低耦合的會怎樣？也即是低內(nèi)聚和高耦合的場景。如果代碼是低內(nèi)聚和高耦合，則會出現(xiàn)修改一個邏輯，會導(dǎo)致多處代碼要修改，這個并不是我們希望看到的，尤其在修改原有的邏輯，很容易出現(xiàn)bug，比如筆者之前修改一個問題，改了另外一處的規(guī)則，看起來是沒有問題，結(jié)果影響到了一個業(yè)務(wù)方，這也是為什么開閉原則提出對修改關(guān)閉的原因，修改原有的邏輯是有風(fēng)險的。

理想的情況是修改只限定在某個局部范圍內(nèi)，這樣影響的范圍有限，因此我們要求邏輯要單一，不要包含多個職責(zé)。再往下思考下：為什么我們要修改呢？除了原有邏輯有bug要修復(fù)、代碼重構(gòu)外，一個重要的原因是需求發(fā)生了變化，是變化導(dǎo)致我們要對原有的邏輯進行修改。如果沒有修改的場景，也就沒有所謂的高內(nèi)聚、低耦合之說了。因此設(shè)計原則的底層邏輯就是讓軟件能夠較好地應(yīng)對變化，降本增效。

3 如何落地實踐

設(shè)計原則只是一個指導(dǎo)的方針，離落地實踐還有很大的一段距離，就像有些同學(xué)說設(shè)計原則我懂了，但我依然運用不到。實際上這個問題的本質(zhì)還是對設(shè)計原則的底層邏輯沒有理解，沒有洞察出變化關(guān)注點，怎么解決這個問題呢？設(shè)計模式給出的答案：找到變化、封裝變化。

五 設(shè)計模式的本質(zhì)

設(shè)計模式請參考筆者之前寫的文章。

六 案例實踐

當(dāng)調(diào)用的接口有不同的實現(xiàn)時（入?yún)ⅰ⒊鰠ⅰ⒔涌诙疾幌嗤枰橄蟪鲆粚臃栏瘜樱趺慈崿F(xiàn)呢？接下來分別看2個案例，這2個案例的側(cè)重點不一樣，一個是偏行為的抽象，一個是偏結(jié)構(gòu)的抽象。

1 店鋪品牌查詢

店鋪需要查詢店鋪品牌信息，然而Lazada和AE的接口是不一樣的，怎么抽象防腐層呢？

首先最簡單的方案很容易想到，就是定義一個接口，然后有兩個實現(xiàn)。它的優(yōu)點是層次簡單，大家基本看了就懂。它的缺點也是明顯的，在兩個實現(xiàn)類中，職責(zé)不一單一，承擔(dān)了兩個職責(zé)：一個是實現(xiàn)店鋪品牌的查詢，另一個是數(shù)據(jù)轉(zhuǎn)換。

根據(jù)方案一提到的缺點，很容易想到使用適配器模式，將之前的類拆成兩個類：一個類是調(diào)用對應(yīng)的品牌服務(wù)；另一個類做數(shù)據(jù)適配轉(zhuǎn)換。不過此時的方式還有一個缺點就是在國際化場景下，要考慮多租戶之間的隔離，比如Lazada有多個站點，如何實現(xiàn)更細粒度的差異呢？方案三基于這些的思考就產(chǎn)生了。

方案三是引入了多租戶框架，能夠支撐多租戶場景。

2 店鋪優(yōu)惠券查詢

有一種"萬金油"式開發(fā)模式：組裝參數(shù)、調(diào)用接口、解析響應(yīng)結(jié)果，你會發(fā)現(xiàn)這種模式太萬能了，適合所有的場景，這樣的開發(fā)模式也即是"事務(wù)腳本模式"或者"面條型代碼"。

優(yōu)惠券查詢的案例，用領(lǐng)域建模的模式，首先思考有哪些實體。優(yōu)惠券查詢的本質(zhì)：通過xx條件查詢返回滿足條件的優(yōu)惠券集合。對于優(yōu)惠券來講，有兩類信息至關(guān)重要。一個是優(yōu)惠券的規(guī)格信息，如優(yōu)惠券名稱、優(yōu)惠金額、有效期等；另一個是優(yōu)惠券的限制條件。在查詢的時候，是查店鋪優(yōu)惠券，還是查粉絲優(yōu)惠券，或者是查詢商品優(yōu)惠券……。因此分開兩部分抽象優(yōu)惠券：一個是優(yōu)惠券查詢請求；另一個是優(yōu)惠券規(guī)格實體。

如果按照這樣的設(shè)計，有一個缺點是業(yè)務(wù)方理解復(fù)雜度會上升，它是偏底層實現(xiàn)，沒有做到使用簡單。優(yōu)惠券偏產(chǎn)品交付而非僅僅功能交付。因此在底層實現(xiàn)之上，再抽象出產(chǎn)品組件，這樣業(yè)務(wù)方使用起來就比較簡單。

作者 | 不拔

原文鏈接：http://click.aliyun.com/m/1000290565/

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。