[[186193]]

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

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

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

得有藥方才行。

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

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

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

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

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

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

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

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

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

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

這個問題是許多開發(fā)人員都容易犯的毛病，尤其對于面向過程設(shè)計的程序員而言，很少會站在對象的角度去思考方法(即行為，準確地說，從設(shè)計的角度講應(yīng)該是對象承擔(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(); 
    } 
} 

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

@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對象，并且解除NodeConfigure與NodeConfigureRepository之間的生命周期依賴。有趣的是getNodeConfigure方法內(nèi)調(diào)用的私有方法。它成了一種設(shè)計的例外，因為在Java中通常需要避免直接對輸入?yún)?shù)進行修改，并將其作為返回結(jié)果。而在這里出現(xiàn)的一系列方法，實則是履行對NodeConfigure對象的數(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) {} 

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

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

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

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

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

第五條：避免“啞對象”

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

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

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

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

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

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

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