代碼診所的第二次診斷
幾年前，我有機會負責一個項目的咨詢。團隊很小，目標是對舊有系統的后端用Java改寫，而團隊的開發人員全為C程序員。我的工作職責是負責項目設計、開發，以及擔任項目開發過程敏捷化的教練，并培養Java開發人員。
我在團隊工作室的墻角落，開了一個小小的診所，廣而告之——“每日一貼，包治百病”。這是當時我在項目上的第二次診斷。
1. 變量的聲明應盡量與使用放在一起
本規則與代碼的可讀性有關，倘若方法還沒有保持短小，這個問題就更要命。或許這是C語言開發者容易犯的毛病。當然也有許多Java程序員從前輩程序員處繼承了這一陋習。我曾經在一個遺留項目中看到過一個長達幾千行的Java方法，在方法頭部堆砌了數十個變量定義，讓人目不暇給!
除了影響代碼的可讀性之外，還可能導致隱藏的缺陷。很多程序員之所以習慣在一開始就聲明變量，就是將這種局部變量當做了存儲中間狀態的容器，在方法內部反復使用該變量，這種中間結果的變遷未必符合開發者意圖，又或者后來的代碼維護者沒有理清這種變化，從而做出變量值的誤判。
2. 對常量和枚舉的使用
本規則本不足道，寫在這里，為了進一步驚醒一下團隊成員。在咨詢過程中，我看到有這段代碼：
- Integer.parseInt(freeFlash, 16);
這個16，究竟是什么鬼?Magic Number，很多時候會讓人感到困惑。
在JDK沒有提供枚舉之前，很多Java程序員喜歡使用接口類型來包裝一大堆常量。如果常量存在內聚的分類意義，還是使用枚舉為佳。
3. 進行合理封裝，避免方法調用順序錯誤
封裝是非常有必要的。有時候，暴露太多的細節會讓調用者感到無可適從。
對于TelnetService類，我們需要依序調用connect()、login()、enterUShell()，然后在執行命令后，必須依序執行exitUShell()，disconnect()。這讓我想起事務處理，FTP訪問等與資源有關的邏輯，都需要在執行邏輯前后包裹一些基礎設施的處理邏輯。為了避免在執行命令前后忘記連接或斷開telnet，***能將此過程封裝。
這是從調用安全性來考慮。
如果從調用的簡潔性考慮，封裝亦有必要。當我們需要通過TelnetService發送telnet命令時，為何還需要了解內部的執行邏輯呢?
那么，該如何封裝才能兩全其美，既滿足對執行邏輯順序的重用，又滿足對命令邏輯的擴展?
通常做法是將真正的執行邏輯提取為接口，如Java中Runnable的方式。這其實可以看作Command模式的運用。當然，我更愿意看做是對函數的封裝，例如Guva中的tranform()、filter()之類的方法，接受更具有函數氣質的Function或者Predicate接口(當時，Java 8還未問世呢)。
因此，我的做法如下：
- public class TelnetService {
- public T withCommand(ExecutionCommand<T> command) {
- connect();
- login();
- enterUShell();
- T result = command.send();
- exitUShell();
- disconnect();
- return result;
- }
- }
可以這樣調用：
- String result = telnetService.withCommand(new ExecutionCommand<String>() {
- @Override
- public String send() {
- return telnetService.transfer();
- }
- }
- );
4. 遵循異常處理的架構規則
團隊成員對異常極為陌生，面對java的受控異常、非受控異常，不知如何選擇;也不知道該何時捕獲異常，何時拋出異常。因而我針對該項目確定了異常處理的架構原則，其目的是為了讓整個架構變得更簡單，讓異常處理更加一致。
我的目的是減輕開發人員的負擔，但同時又不降低代碼質量，并利于未來對代碼的維護。規則如下：
- 同層之間的調用不做try-catch，上層調用下層的對象，必須try-catch。即使對象拋出了異常，只要不是checked exception(我們盡量避免使用checked exception，以避免它對接口的污染)，就無需考慮去捕獲這個異常。這樣的設計并不會導致異常泄露，因為我們要求在上一層捕獲。至于最頂端的Application Layer，則只做捕獲異常的事兒，不干拋異常的活兒。
- 為各層(即領域層和基礎設施層)定義各自的異常超類。其中，領域層定義的異常要求提供Error Code。Error Code并非我所愿，但對于本系統的上游系統，卻需要該值，不得不為。
- 領域層。若是結合實際情況由自己拋出異常，則只需考慮異常消息和錯誤碼;若是捕獲了異常再拋出，則在捕獲時記錄日志，再度拋出的異常需要包裹原始異常對象。
在代碼診所中診斷出來的疾病，可以作為代碼評審的一個標準，同時這些處方則可以當做團隊內部分享與交流的知識庫。長期累積下來，非常有利于團隊成員編碼能力的成長。
【本文為51CTO專欄作者“張逸”原創稿件，轉載請聯系原作者】
