幾年前，我有機會負責一個項目的咨詢。團隊很小，目標是對舊有系統的后端用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);
