[[186193]]

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

C程序員的一個特點是基本不具備面向對象知識，在初步掌握Java語法之后，寫出來的代碼還是過程化的代碼。團隊開發人員的現狀就是：沒有Clean Code的意識，不知道何謂TDD與重構，寫出來的Java代碼質量很糟。如果從項目開初不針對這一問題進行有效的防治，就可能導致整個代碼庫陷入泥沼之中。

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

得有藥方才行。

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

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

***條：應隨時保持架構的清晰與簡單：統一所有查詢為Repository。

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

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

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

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

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

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

第三條：方法名體現意圖。

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

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

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

@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方法內調用的私有方法。它成了一種設計的例外，因為在Java中通常需要避免直接對輸入參數進行修改，并將其作為返回結果。而在這里出現的一系列方法，實則是履行對NodeConfigure對象的數據收集，因而可以定義為：

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) {} 

我對這些方法的名稱進行了修改，使其能夠更好地展現其意圖。于是，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模式的簡化設計。當然，我們也可以運用Builder模式對NodeConfigure對象進行組裝。

第四條：同一個方法中的實現代碼應處于同一抽象層次。

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

第五條：避免“啞對象”

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

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

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

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

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

【本文為51CTO專欄作者“張逸”原創稿件，轉載請聯系原作者】

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