[[186193]]

幾年前，我有機(jī)會(huì)負(fù)責(zé)一個(gè)項(xiàng)目的咨詢。團(tuán)隊(duì)很小，目標(biāo)是對(duì)舊有系統(tǒng)的后端用Java改寫，而團(tuán)隊(duì)的開發(fā)人員全為C程序員。我的工作職責(zé)是負(fù)責(zé)項(xiàng)目設(shè)計(jì)、開發(fā)，以及擔(dān)任項(xiàng)目開發(fā)過程敏捷化的教練，并培養(yǎng)Java開發(fā)人員。

C程序員的一個(gè)特點(diǎn)是基本不具備面向?qū)ο笾R(shí)，在初步掌握J(rèn)ava語法之后，寫出來的代碼還是過程化的代碼。團(tuán)隊(duì)開發(fā)人員的現(xiàn)狀就是：沒有Clean Code的意識(shí)，不知道何謂TDD與重構(gòu)，寫出來的Java代碼質(zhì)量很糟。如果從項(xiàng)目開初不針對(duì)這一問題進(jìn)行有效的防治，就可能導(dǎo)致整個(gè)代碼庫陷入泥沼之中。

為此，我要求在每日站會(huì)之后及時(shí)開展了代碼評(píng)審活動(dòng)。評(píng)審過程中，只能以我為主導(dǎo)，幫助大家發(fā)現(xiàn)代碼的壞味道。從一開始，具有壞味道的代碼可謂俯拾皆是，就像我們每天都在呼吸污染了的空氣一般不可避免。要凈化空氣任重而道遠(yuǎn)，要讓團(tuán)隊(duì)成員寫出好的代碼，同樣任重而道遠(yuǎn)。

得有藥方才行。

于是我當(dāng)起了診治代碼疾病的醫(yī)生。為了更容易傳播醫(yī)療知識(shí)，我在團(tuán)隊(duì)工作室的墻角落，開了一個(gè)小小的診所，廣而告之——“每日一貼，包治百病”。剛開張時(shí)，診所門面還沒裝修好，所以直接找了個(gè)白板開出了一個(gè)藥方：

個(gè)人認(rèn)為，這些處方不僅僅對(duì)于當(dāng)時(shí)的客戶團(tuán)隊(duì)有療效，可能也適合大多數(shù)開發(fā)團(tuán)隊(duì)。幾年過去了，我把這些處方分享出來，也算是一個(gè)小小的總結(jié)吧。先來看看這些處方吧。

***條：應(yīng)隨時(shí)保持架構(gòu)的清晰與簡(jiǎn)單：統(tǒng)一所有查詢?yōu)镽epository。

項(xiàng)目其實(shí)并不需要訪問數(shù)據(jù)庫，而是通過遠(yuǎn)程的Telnet(或其他協(xié)議)去訪問前端的設(shè)備。然而，我們可以借鑒DDD中資源庫的這個(gè)隱喻。至于提到的架構(gòu)，則是我在架構(gòu)設(shè)計(jì)時(shí)參考了DDD的分層邏輯架構(gòu)。

為保證架構(gòu)的簡(jiǎn)單與清晰，我做了一些“一刀切”的簡(jiǎn)化原則：例如對(duì)Repository和Service的定義。通過Telnet等網(wǎng)絡(luò)協(xié)議獲取設(shè)備信息的功能不妨看做是對(duì)DB的查詢。因而，諸如NodeConfigureGetter這樣的類就應(yīng)該統(tǒng)一命名為NodeConfigureRepository。

該處方的主要目的是為了保持代碼的一致性，若不加以規(guī)范，就會(huì)出現(xiàn)Getter、Finder、Query等各種不統(tǒng)一的類名后綴，讓人眼花繚亂。

第二條：依賴注入(對(duì)象之間的協(xié)作)

很多OO初學(xué)者并不能理解依賴注入。我的一個(gè)辦法是讓他們從可測(cè)試性的角度出發(fā)。例如，倘若在NodeConfigureRepository類中直接實(shí)例化了TelnetService(這個(gè)類提供連接、登錄、執(zhí)行命令等與Telnet有關(guān)的操作)，那么該怎樣在不需要Telnet環(huán)境的基礎(chǔ)上為NodeConfigureRepository編寫單元測(cè)試呢?解決不了這樣的問題，就說明設(shè)計(jì)的可測(cè)試性不夠好。

解決方案就是依賴注入。當(dāng)時(shí)的項(xiàng)目并未引入第三方IoC容器，原因在于項(xiàng)目的Jar包需要和另一個(gè)系統(tǒng)協(xié)作，并駐留在Flash中。容量有限，不允許引入太多第三方包，保證Jar包的精悍。

第三條：方法名體現(xiàn)意圖。

這個(gè)問題是許多開發(fā)人員都容易犯的毛病，尤其對(duì)于面向過程設(shè)計(jì)的程序員而言，很少會(huì)站在對(duì)象的角度去思考方法(即行為，準(zhǔn)確地說，從設(shè)計(jì)的角度講應(yīng)該是對(duì)象承擔(dān)的職責(zé))。例如在NodeConfigureRepository類中，開發(fā)人員定義了getNodeConfigure方法，但返回值卻是void：

public NodeConfigureRepository { 
    private NodeConfigure configure; 
    public NodeConfigureRepository(NodeConfigure configure) { 
        this.configure = configure; 
    } 
    public void getNodeConfigure() { 
        getMasterLogicBoard(); 
        getMasterIp(); 
        getEnvId(); 
        getMasterSlot(); 
        getSlaveIp(); 
        getSlaveBoardTypeAndStatus(); 
    } 
} 

這個(gè)方法調(diào)用的諸多私有方法實(shí)則都是對(duì)構(gòu)造函數(shù)傳入的NodeConfigure進(jìn)行數(shù)據(jù)收集。這樣的定義不僅讓代碼的調(diào)用者感覺怪怪的，測(cè)試也變得極為詭異：

@Test 
public void should_get_main_ctrl_logic_board_type() { 
    configure = Nodeconfigure(); 
    configureRepository = new NodeConfigureRepository(configure); 
    configureRepository.getNodeConfigure(); 
 
    assertThat(configure.getMasterLogicBoard(), is(12288)); 
} 

怎么改?

方法就是讓getNodeConfigure()方法直接返回組裝之后的NodeConfigure對(duì)象，并且解除NodeConfigure與NodeConfigureRepository之間的生命周期依賴。有趣的是getNodeConfigure方法內(nèi)調(diào)用的私有方法。它成了一種設(shè)計(jì)的例外，因?yàn)樵贘ava中通常需要避免直接對(duì)輸入?yún)?shù)進(jìn)行修改，并將其作為返回結(jié)果。而在這里出現(xiàn)的一系列方法，實(shí)則是履行對(duì)NodeConfigure對(duì)象的數(shù)據(jù)收集，因而可以定義為：

private void  collectMasterLogicBoard(NodeConfigure configure) {} 
private void  collectMasterIp(NodeConfigure configure) {} 
private void  collectEnvId(NodeConfigure configure) {} 
private void  collectMasterSlot(NodeConfigure configure) {} 
private void  collectSlaveIp(NodeConfigure configure) {} 
private void  collectSlaveBoardTypeAndStatus(NodeConfigure configure) {} 

我對(duì)這些方法的名稱進(jìn)行了修改，使其能夠更好地展現(xiàn)其意圖。于是，getNodeConfigure()就變成了：

public NodeConfigure getNodeConfigure() { 
   NodeConfigure configure = new NodeConfigure(); 
   collectMasterLogicBoard(configure); 
   collectMasterIp(configure); 
   collectEnvId(configure); 
   collectMasterSlot(configure); 
   collectSlaveIp(configure); 
   collectSlaveBoardTypeAndStatus(configure); 
   return configure;} 

這里實(shí)際上是Kent Beck提出的Collected Parameter模式。它是Visitor模式的簡(jiǎn)化設(shè)計(jì)。當(dāng)然，我們也可以運(yùn)用Builder模式對(duì)NodeConfigure對(duì)象進(jìn)行組裝。

第四條：同一個(gè)方法中的實(shí)現(xiàn)代碼應(yīng)處于同一抽象層次。

這其實(shí)是老生常談了。Kent Beck在Smalltalk Best Practice Patterns一書中提到了“組合方法”模式，建議“讓一個(gè)方法中的所有操作處于相同的抽象層”，即所謂的SLAP原則。在Robert Martin的Clean Code一書中也反復(fù)提到這一原則，Neal Ford在Emergent Design也有詳細(xì)描述。

第五條：避免“啞對(duì)象”

這里展現(xiàn)的壞味道，在Martin Fowler的Refactoring一書中已有提及。在項(xiàng)目中，存在一些操作Xml文件的操作，并將這些Xml文件的Element映射為了Java對(duì)象。我們沒有使用Jaxb，因?yàn)閷?duì)于我們有限的xml操作而言，Jaxb還是顯得太重。然而，在我們的代碼中，包括PackageStatusFileParser、StoragePackageGenerator、DownloadingConfigureParser等類中都存在著將Xml Element轉(zhuǎn)換為PackageInfo、SoftInfo等對(duì)象的重復(fù)代碼。

原因就在于我們將這些對(duì)象看做了“啞”的數(shù)據(jù)對(duì)象，而沒有將這種轉(zhuǎn)換行為封裝到擁有這些數(shù)據(jù)的對(duì)象中(我們的轉(zhuǎn)換僅牽涉到Xml，沒有擴(kuò)展可能，因而無需使用Visitor模式)。

除了會(huì)導(dǎo)致大量的重復(fù)代碼之外，一旦轉(zhuǎn)換邏輯發(fā)生變化，例如XmlElement增加了Attribute，就可能需要到處修改，形成所謂的“霰彈式修改”。因而需要將這些邏輯封裝到對(duì)象中，例如：

public class PackgeInfo { 
    public PackageInfo createFrom(Elment element) {} 
} 
PackageInfo packageInfo = PackageInfo.createFrom(element); 

代碼雖為細(xì)節(jié)末道，看似微末，然而在項(xiàng)目開始之初不加以規(guī)范與約束，而任其腐化蔓延，最終造成的苦果還是會(huì)反擊到整個(gè)系統(tǒng);待到代碼質(zhì)量已經(jīng)墮落到不可修復(fù)的地步時(shí)，再要挽回，可能已經(jīng)覆水難收了。

【本文為51CTO專欄作者“張逸”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文