[[333767]]

關于代碼的健壯性，其重要性不言而喻。那么如何才能寫出健壯的代碼?阿里文娛技術專家長統(tǒng)將從防御式編程、如何正確使用異常和 DRY 原則等三個方面，并結合代碼實例，分享自己的看法心得，希望對同學們有所啟發(fā)。

你不可能寫出完美的軟件。因為它不曾出現(xiàn)，也不會出現(xiàn)。

每一個司機都認為自己是最好的司機，我們在鄙視那些闖紅燈、亂停車、胡亂變道不遵守規(guī)則的司機同時，更應該在行駛的過程中防衛(wèi)性的駕駛，小心那些突然沖出來的車輛，在他們給我們造成麻煩的時候避開他。這跟編程有極高的相似性，我們在程序的世界里要不斷的跟他人的代碼接合(那些不符合你的高標準的代碼)，并處理可能有效也可能無效的輸入。無效的的輸入就好像一輛橫沖直撞的大卡車，這樣的世界防御式編程也是必須的，但要駛得萬年船我們可能連自己都不能信任，因為你不知道沖出去的那輛是不是你自己的車。關于這點我們將在防御式編程中討論。

沒人能否認異常處理在 Java 中的重要性，但如果不能正確使用異常處理那么它帶來的危害可能比好處更多。我將在正確使用異常中討論這個問題。

DRY,Don't Repeat Yourself. 不要重復你自己。我們都知道重復的危害性，但重復時常還會出現(xiàn)在我們的工作中、代碼中、文檔中。有時重復感覺上是不得不這么做，有時你并沒有意識到是在重復，有時卻是因為懶惰而重復。

好借好還再借不難。這句俗話在編程世界中同樣也是至理名言。只要在編程，我們都要管理資源：內存、事物、線程、文件、定時器，所有數(shù)量有限的事物都稱為資源。資源使用一般遵循的模式：你分配、你使用、你回收。

防御式編程

防御式編程是提高軟件質量技術的有益輔助手段。防御式編程的主要思想是：程序/方法不應該因傳入錯誤數(shù)據(jù)而被破壞，哪怕是其他由自己編寫方法和程序產生的錯誤數(shù)據(jù)。這種思想是將可能出現(xiàn)的錯誤造成的影響控制在有限的范圍內。

一個好程序，在非法輸入的情況下，要么什么都不輸出，要么輸出錯誤信息。我們往往會檢查每一個外部的輸入(一切外部數(shù)據(jù)輸入，包括但不僅限于數(shù)據(jù)庫和配置中心)，我們往往也會檢查每一個方法的入?yún)ⅰＮ覀円坏┌l(fā)現(xiàn)非法輸入，根據(jù)防御式編程的思想一開始就不引入錯誤。

使用衛(wèi)語句

對于非法輸入的檢查我們通常會使用 if…else 去做判斷，但往往在判斷過程中由于參數(shù)對象的層次結構會一層一層展開判斷。

public void doSomething(DomainA a) { 
  if (a != null) { 
        assignAction; 
    if (a.getB() != null) { 
      otherAction; 
      if (a.getB().getC() instanceof DomainC) { 
        doSomethingB(); 
        doSomethingA(); 
        doSomthingC(); 
      } 
    } 
  } 
} 

上邊的嵌套判斷的代碼我相信很多人都見過或者寫過，這樣做雖然做到了基本的防御式編程，但是也把丑陋引了進來。《Java 開發(fā)手冊》中建議我們碰到這樣的情況使用衛(wèi)語句的方式處理。什么是衛(wèi)語句?我們給出個例子來說明什么是衛(wèi)語句。

public void doSomething(DomainA a) { 
    if (a == null) { 
        return ; //log some errorA 
    } 
    if (a.getB() == null) { 
        return ; //log some errorB 
    } 
    if (!(a.getB().getC instanceof DomainC)) { 
        return ;//log some errorC 
    } 
    assignAction; 
    otherAction; 
    doSomethingA(); 
    doSomethingB(); 
    doSomthingC(); 
} 

方法中的條件邏輯使人難以看清正常的分支執(zhí)行路徑，所謂的衛(wèi)語句的做法就是將復雜的嵌套表達式拆分成多個表達式，我們使用衛(wèi)語句表現(xiàn)所有特殊情況。

使用驗證器 (validator)

驗證器是我在開發(fā)中的一種實踐，將合法性檢查與 OOP 結合是一種非常奇妙的體驗。

public List<DemoResult> demo(DemoParam dParam) { 
    Assert.isTrue(dParam.validate(),()-> new SysException("參數(shù)驗證失敗-" + DemoParam.class.getSimpleName() +"驗證失敗：" + dParam)); 
    DemoResult demoResult = doBiz(); 
    doSomething(); 
    return demoResult; 
} 

在這個示例中，方法的第一句話就是對驗證器的調用，以獲得當前參數(shù)是否合法。

在參數(shù)對象中實現(xiàn)驗證接口，為字段配置驗證注解，如果需要組合驗證復寫 validate0 方法。這樣就把合法性驗證邏輯封裝到了對象中。

public class DemoParam extends BaseDO implements ValidateSubject { 
    @ValidateString(strMaxLength = 128) 
    private String aString; 
    @ValidateObject(require = true) 
    private List<SubjectDO> bList; 
    @ValidateString(require = true,strMaxLength = 128) 
    private String cString; 
    @ValidateLong(require = true) 
    private Long dLong; 
    @Override 
    public boolean validate0(ValidateSubject validateSubject) throws ValidateException { 
        if (validateSubject instanceof DemoParam) { 
            DemoParam param = (DemoParam)validateSubject; 
            return StringUtils.isNotBlank(param.getAString()) 
                   && SubjectDO.allValidate(param.getBList()); 
        } 
        return false; 
    } 
} 

使用斷言

當出現(xiàn)了一個突如其來的線上問題，我相信很多伙伴的心中一定閃現(xiàn)過這樣一個念頭。"這不科學啊...這不可能發(fā)生啊…"，"計數(shù)器怎么可能為負數(shù)"，"這個對象不可為null"，但它就是真實的發(fā)生了，它就在那。我們不要這樣騙自己，特別是在編碼時。如果它不可能發(fā)生，用斷言確保它不會發(fā)生。

使用斷言的重要原則就是，斷言不能有副作用，也絕不能把必須執(zhí)行的代碼放入斷言。

斷言不能有副作用，如果我每年增加錯誤檢查代碼卻制造了新的錯誤，那是一件令人尷尬的事情。舉一個反面例子：

while (iter.next() != null) { 
    assert(iter.next()!=null); 
    Object next = iter.next(); 
    //... 
} 

必須執(zhí)行的代碼也不能放入斷言，因為生產環(huán)境很可能是關閉 Java 斷言的。因此我更喜歡使用 Spring 提供的 Assert 工具，這個工具提供的斷言只會返回 IllegalStateException，如果需要這個異常不能滿足我們的業(yè)務需求，我們可以重新創(chuàng)建一個 Assert 類并繼承org.springframework.util.Assert，在新類中新增斷言方法以支持自定義異常的傳入。

public class Assert extends org.springframework.util.Assert { 
    public static <T extends RuntimeException> void isTrue(boolean expression, Supplier<T> tSupplier) { 
        if (!expression) { 
            if (tSupplier != null) { 
                throw tSupplier.get(); 
            } 
            throw new IllegalArgumentException(); 
        } 
    } 
} 

Assert.isTrue(crParam.validate(),()-> new SysException("參數(shù)驗證失敗-" + Calculate.class.getSimpleName() +"驗證失敗：" + crParam)); 

有人認為斷言僅是一種調試工具，一旦代碼發(fā)布后就應該關閉斷言，因為斷言會增加一些開銷(微小的 CPU 時間)。所以在很多工程實踐中斷言確實是關閉的，也有不少大 V 有過這樣的建議。Dndrew Hunt 和 David Thomas 反對這樣的說法，在他們書里有一個比喻我認為很形象。

在你把程序交付使用時關閉斷言就像是因為你曾經成功過，就不用保護網取走鋼絲。

——《The pragmatic Programmer》

處理錯誤時的關鍵選擇

防御式編程會預設錯誤處理。

在錯誤發(fā)生后的后續(xù)流程上通常會有兩種選擇，終止程序和繼續(xù)運行。

• 終止程序，如果出現(xiàn)了非常嚴重的錯誤，那最好終止程序或讓用戶重啟程序。比如，銀行的 ATM 機出現(xiàn)了錯誤，那就關閉設備，以防止取 100 塊吐出 10000 塊的悲劇發(fā)生。
• 繼續(xù)運行，通常也是有兩種選擇，本地處理和拋出錯誤。本地處理通常會使用默認值的方式處理，拋出錯誤會以異常或者錯誤碼的形式返回。

在處理錯誤的時候我們還面臨著另外一種選擇，正確性和健壯性的選擇。

• 正確性，選擇正確性意味著結果永遠是正確的，如果出錯，寧愿不給出結果也不要給定一個不準確的值。比如用戶資產類的業(yè)務。
• 健壯性，健壯性意味著通過一些措施，保證軟件能夠正常運行下去，即使有時候會有一些不準確的值出現(xiàn)。比如產品介紹超過頁面展示范圍

無論是使用衛(wèi)語、斷言還是預設錯誤處理都是在用抱著對程序世界的敬畏態(tài)度在小心的駕駛，時刻提防著他人更提防著自己。

北京第三區(qū)交通委提醒您，道路千萬條，安全第一條，行車不規(guī)范，親人兩行淚。

正確使用異常

檢查每一個可能的錯誤是一種良好的實踐，特別是那些意料之外的錯誤。

非常棒的是，Java 為我們提供了異常機制。如果充分發(fā)揮異常的優(yōu)點，可以提高程序的可讀性、可靠性和可維護性，但如果使用不當，異常帶來的負面影響也是非常值得我們注意并避免的。

只在異常情況下使用異常

在《The pragmatic Programmer》和《Effective Java》中作者都有這樣的觀點。

我認為這有兩重意思。一重意思如何處理識別異常情況并處理他，另一重意思是只在異常情況下使用異常流程。

那什么是異常情況，又該如何處理?這個問題無法在代碼模式上給出標準的答案，完全看實際情況，要對每一個錯誤了然于胸并檢查每一個可能發(fā)生的錯誤，并區(qū)分錯誤和異常。

即便同樣是打開文件操作，讀取"/etc/passwd"和讀取一個用戶上傳的文件，同樣是 FileNotFoundException，如何處理完全取決于實際情況，Surprise!前者直接讀取文件出現(xiàn)異常直接拋出讓程序盡早崩潰，而后者應該先判斷文件是否存在，如果存在但出現(xiàn)了 FileNotFoundException 則再拋出。

public static void openPasswd() throws FileNotFoundException { 
        FileInputStream fs = new FileInputStream("/etc/passwd"); 
    } 

讀取"/etc/passwd"失敗，Surprise!

public static boolean openUserFile(String path) throws FileNotFoundException { 
       File f = new File(path); 
       if (!f.exists()) { 
           return false; 
       } 
       FileInputStream fs = new FileInputStream(path); 
       return true; 
   } 

在文件存在的情況下讀取文件失敗，Surprise!

再啰嗦一遍，是不是異常情況關鍵在于它是不是給我們一記 Surprise!，這就是本節(jié)開頭檢查每一個錯誤是一種良好的實踐想要表達的。

使用異常來控制正常流程的反面例子我就偷懶借用一下《Effective Java Second Edition》里的例子來說明好了。

Integer[] range ={1,2,3}; 
//Horrible abuse of exceptions.Don't ever do this! 
try { 
  int i=0; 
  println(range[i++].intValue()); 
} catch (ArrayIndexOutOfBoundsException e) {} 

這個例子看起來根本不知道在干什，這段代碼其實是在用數(shù)組越界異常來控制遍歷數(shù)組，這個腦洞開的非常拙劣。如何正確遍歷一個數(shù)組我想不需要再給出例子，那是對讀者的褻瀆。

那為什么有人這么開腦洞呢?因為這個做法企圖使用 Java 錯誤判斷機制來提高性能，因為 JVM 對每一次數(shù)組訪問都會檢查越界情況，所以他們認為檢查到的錯誤才應該是循環(huán)終止的條件，然而 for-each 循環(huán)對已經檢查到的錯誤視而不見，將其隱藏了，所以用應該避免使用 for-each。

對于這個腦洞的原因 Joshua Bloch 給出了三點反駁：

• 因為異常機制的設計初衷是用于不正常的情形，所以很少會有 JVM 實現(xiàn)試圖對它們進行優(yōu)化，使得與顯示測試一樣快速。
• 把代碼放在 try-catch 塊中反而阻止了現(xiàn)代 JVM 實現(xiàn)本來可能要執(zhí)行的某些特定優(yōu)化。
• 對數(shù)組進行遍歷的標準模式并不會導致冗余的檢查。有些現(xiàn)代的 JVM 實現(xiàn)會將他們優(yōu)化掉。

還有一個例子是我曾經遇到的，但是由于年代久遠已經找不到項目地址了。我一個朋友曾經給我看過一個 github 上的 MVC 框架項目，雖然時隔多年但令我印象深刻的是這個項目使用自定義異常和異常碼來控制 Dispatcher，把異常當成一種方便的結果傳遞方式來使用，當成 goto 來使用，這太可怕了。不過 try-catch 方式從字節(jié)碼表述上來看，確實是一種 goto 的表述。這樣的方式我們最好想都不要想。

這兩個例子主要就是為了說明，異常應該只用于異常的情況下;永遠不應該用在正常的流程中，不管你的理由看著多么的聰明。這樣做往往會弄巧成拙，使得代碼可讀性大大下降。

受檢異常和非受檢異常

曾經不止一次的見過有人提倡將系統(tǒng)中的受檢異常都包裝成非受檢異常，對于這個建議我并不以為然。因為 Java 的設計者其實是希望通過區(qū)分異常種類來指導我們編程的。

Java 一共提供了三類可拋出結構 (throwable)，受檢異常、非受檢異常(運行時異常)和錯誤 (error)。他們的界限我也經常傻傻的分不清，不過還是有跡可循的。

• 受檢異常：如果期望調用者能夠適當?shù)幕謴停热?RMI 每次調用必須處理的異常，設計者是期望調用者可以重試或別的方式來嘗試恢復;比如上邊提到的 FileInputStream 的構造方法，會拋出 FileNotFoundException，設計者或許希望調用者嘗試從其他目錄來讀取該文件，使得程序可以繼續(xù)執(zhí)行下去。
• 非受檢異常和錯誤：表明是編程錯誤，往往屬于不可恢復的情景，而且是不應該被提前捕獲的，應該快速拋出到頂層處理器，比如在服務接口的基類方法中統(tǒng)一處理非受檢異常。這種非受檢異常往往也說明了在編程中違反了某些約定。比如數(shù)組越界異常，說明違反了訪問數(shù)組不能越界的前提約定。

總而言之，對于可恢復的情況使用受檢異常;對于程序錯誤使用非受檢異常。因此你自己程序內部定義的異常都應該是非受檢異常;在面向接口或面向二方/三方庫的方法盡量使用受檢異常。

說到面向接口或面向二/三方庫，你可能碰到的就是一輛失控的汽車。搞清楚你所調用的接口或者庫里的異常情況也是我們能夠碼出健壯代碼的一個強力保證。

不要忽略異常

這個建議顯而易見，但卻常常被違反。當一個 API 的設計者聲明一個方法將拋出異常的時候，通常都是想要說明某件事發(fā)生了。忽略異常就是我們通常說的吃掉異常，try-catch 但什么也不做。吃掉一個異常就好比破壞了一個報警器，當災難真正來臨沒人搞清楚發(fā)生了什么。

對于每一個 catch 塊至少打印一條日志，說明異常情況或者說明為什么不處理。

這個顯而易見的建議同時適用于受檢異常和非受檢異常。

DRY (Don't Repeat Yourself)

DRY 原則最先在《The pragmatic Programmer》被提出，如今已經被業(yè)界廣泛的認知，我相信每個軟件工程師都認識它。我想有很多人對它的認識含混不清僅僅是不要有重復的代碼;也有些人對此原則不屑一顧抽象什么的都是浪費時間快速上線是大義;也有人誓死捍衛(wèi)這個原則不能忍受任何重復。今天我們來談談這個熟悉又陌生的話題。

DRY 是什么

DRY 的原則是“系統(tǒng)中的每一部分，都必須有一個單一的、明確的、權威的代表”，指的是(由人編寫而非機器生成的)代碼和測試所構成的系統(tǒng)，必須能夠表達所應表達的內容，但是不能含有任何重復代碼。當 DRY 原則被成功應用時，一個系統(tǒng)中任何單個元素的修改都不需要與其邏輯無關的其他元素發(fā)生改變。此外，與之邏輯上相關的其他元素的變化均為可預見的、均勻的，并如此保持同步。

這段定義來自于中文維基百科，但這個定義似乎與 Andrew Hunt 和 David Thomas 給出的定義有所出入。尋根溯源在《The pragmatic Programmer》作者是這樣定義這個原則的：

EVERY PIECE OF KNOWLEDGE MUST HAVE A SINGLE, UNAMBIGUOUS, AUTHORITATIVE REPRESENTATION WITHIN A SYSTEM.

系統(tǒng)中的每一項知識都必須具有單一、無歧義、權威的表示。

作者所提倡禁止的是知識 (knowledge) 的重復而不是單純的代碼上的重復。那什么是知識呢?我斗膽給一個自己的理解，知識就是系統(tǒng)中對于一個邏輯的解釋/定義，系統(tǒng)中的邏輯都是要對外輸出或者讓外界感知的。邏輯的定義/解釋包括代碼和寫在代碼上的文檔還有宏觀上實現(xiàn)。我們要避免的是在改動時的一個邏輯的時候需要去修改十處，如果漏掉了任何一處就會造成 bug 甚至線上故障。變更在軟件開發(fā)中又是一個常態(tài)，在互聯(lián)網行業(yè)中更是如此，而在一個到處是重復的系統(tǒng)中維護變更是非常艱難的。

沒有文檔比錯誤的文檔更好

編寫代碼時同時編寫文檔在多數(shù)程序員看來是一個好習慣，但有相當一部分程序開發(fā)人員又沒有這樣的習慣，這一點反而使得代碼更干 (dry)——有點好笑。因為底層知識應該放在代碼中，底層代碼應該是職責單一、邏輯簡單的代碼，在底層代碼上添加注釋就是在做重復的事情，就有可能因為對于知識的過期解釋，而讀注釋比讀代碼更容易，可怕的事情往往就這樣發(fā)生;把注釋放在更上層的復雜的復雜邏輯中。滿篇的注釋并不是好代碼，也不是好習慣，好的代碼是不需要注釋的。

CP 大法，禁止!

每個項目都有時間壓力，這往往是誘惑我們使用 CP 大法最重要原因。但是"欲速則不達"，你也許現(xiàn)在省了十分鐘，以后卻需要花幾個小時處理各種各樣的線上問題。因為變更是常態(tài)，我們當初留下的一個坑隊友可能會幫你挖的更深更大一些，然后我們就掉進了自己挖的坑，我們還會埋怨豬隊友，到底誰才是豬隊友。這其實是我?guī)н^的一個團隊里真實發(fā)生的事情。

把知識的解釋/定義放在一處!

PS：感受一下程序員的冷幽默。違背 DRY 原則的代碼，程序員稱之為 WET 的，可以理解為 Write Everything Twice(任何東西寫兩遍)，We Enjoying Typing(我們享受敲鍵盤)或 Waste Everyone’s Time(浪費所有人的時間)。

關于 DRY 原則的爭論

DRY 原則提出以來一直以來都存在著一些爭議和討論，有粉也有黑。如果有一個百分比，對于這條原則我會選擇 95% 服從。

《The pragmatic Programmer》告訴我們 Once and only once。

《Extreme Programing》又告訴我們 You aren't gonna need it (YAGNI)，指的是你自以為有用的功能，實際上都是用不到的。這里好像出現(xiàn)了一個問題，DRY 與 YAGNI 不完全兼容。DRY 要求花精力去抽象追求通用，而 YAGNI 要求快和省，你花精力做的抽象很可能用不到。

這個時候我們的第三選擇是什么?《Refactoring》提出的 Rule Of Three 像是一個很好的折中方案。它的涵義是，第一次用到某個功能時，你寫一個特定的解決方法;第二次又用到的時候，你拷貝上一次的代碼;第三次出現(xiàn)的時候，你才著手"抽象化"，寫出通用的解決方法。這樣做有幾個理由：

省事

如果一種功能只有一到兩個地方會用到，就不需要在"抽象化"上面耗費時間了。

容易發(fā)現(xiàn)模式

"抽象化"需要找到問題的模式，問題出現(xiàn)的場合越多，就越容易看出模式，從而可以更準確地"抽象化"。比如，對于一個數(shù)列來說，兩個元素不足以判斷出規(guī)律：

1，2，_，_，_，_ 

第三個元素出現(xiàn)后，規(guī)律就變得較清晰了：

1，2，4，_，_，_ 

防止過度冗余

如果一種功能同時有多個實現(xiàn)，管理起來非常麻煩，修改的時候需要修改多處。在實際工作中，重復實現(xiàn)最多可以容忍出現(xiàn)一次，再多就無法接受了。

我認為以上三個原則都不能當做銀彈，還是要根據(jù)實際情況做出正確的選擇。

DRY 原則理論上來說是沒有問題的，但在實際應用時切忌死搬教條。它只能起指導作用，沒有量化標準，否則的話理論上一個程序每一行代碼都只能出現(xiàn)一次才行，這是非常荒謬的。

Rule of Three 不是重復的代碼一定要出現(xiàn)三次才可以進行抽象，我認為三次不應該成為一個度量標準，對于未來的預判和對于項目走向等因素也應該放在是否抽象的考慮中。

PS：王垠曾經寫過一篇《DRY 原則的危害》有興趣的朋友可以讀一讀：如何評價王垠最新文章，《DRY 原則的危害》?

(https://www.zhihu.com/question/31278077)

后記

原則不是銀彈，原則是沙漠中的綠洲亦或是沙漠中海市蜃樓中的綠洲。面對所謂的原則要求我們每一個人都有辨識能力，不盲目遵從先哲大牛，要具有獨立思考的能力。具備辨識和思考能力首先就需要有足夠多的輸入和足夠多的實踐。

參考

[1]《The pragmatic Programmer：From Journeyman to Master》 作者：Andrew Hunt、David Thomas[2]《Effective Java Second Edition》 作者 ：Joshua Bloch[3]《Java 開發(fā)手冊》[4]中文維基百科[5]代碼的抽象三原則-阮一峰

 

http://www.ruanyifeng.com/blog/2013/01/abstraction_principles.html