日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關咨詢
選擇下列產品馬上在線溝通
服務時間：8:30-17:00
你可能遇到了下面的問題
關閉右側工具欄

新聞中心

這里有您想知道的互聯(lián)網營銷解決方案
代碼診所的第二次診斷

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

創(chuàng)新互聯(lián)公司專注于成都網站建設、網站建設、網頁設計、網站制作、網站開發(fā)。公司秉持“客戶至上,用心服務”的宗旨,從客戶的利益和觀點出發(fā),讓客戶在網絡營銷中找到自己的駐足之地。尊重和關懷每一位客戶，用嚴謹?shù)膽B(tài)度對待客戶，用專業(yè)的服務創(chuàng)造價值，成為客戶值得信賴的朋友，為客戶解除后顧之憂。

我在團隊工作室的墻角落，開了一個小小的診所，廣而告之——“每日一貼，包治百病”。這是當時我在項目上的第二次診斷。

1. 變量的聲明應盡量與使用放在一起

本規(guī)則與代碼的可讀性有關，倘若方法還沒有保持短小，這個問題就更要命。或許這是C語言開發(fā)者容易犯的毛病。當然也有許多Java程序員從前輩程序員處繼承了這一陋習。我曾經在一個遺留項目中看到過一個長達幾千行的Java方法，在方法頭部堆砌了數(shù)十個變量定義，讓人目不暇給!

除了影響代碼的可讀性之外，還可能導致隱藏的缺陷。很多程序員之所以習慣在一開始就聲明變量，就是將這種局部變量當做了存儲中間狀態(tài)的容器，在方法內部反復使用該變量，這種中間結果的變遷未必符合開發(fā)者意圖，又或者后來的代碼維護者沒有理清這種變化，從而做出變量值的誤判。

2. 對常量和枚舉的使用

本規(guī)則本不足道，寫在這里，為了進一步驚醒一下團隊成員。在咨詢過程中，我看到有這段代碼：

 
 
 
    
  
  
  
  1. Integer.parseInt(freeFlash, 16);
    2.

這個16，究竟是什么鬼?Magic Number，很多時候會讓人感到困惑。

在JDK沒有提供枚舉之前，很多Java程序員喜歡使用接口類型來包裝一大堆常量。如果常量存在內聚的分類意義，還是使用枚舉為佳。

3. 進行合理封裝，避免方法調用順序錯誤

封裝是非常有必要的。有時候，暴露太多的細節(jié)會讓調用者感到無可適從。

對于TelnetService類，我們需要依序調用connect()、login()、enterUShell()，然后在執(zhí)行命令后，必須依序執(zhí)行exitUShell()，disconnect()。這讓我想起事務處理，F(xiàn)TP訪問等與資源有關的邏輯，都需要在執(zhí)行邏輯前后包裹一些基礎設施的處理邏輯。為了避免在執(zhí)行命令前后忘記連接或斷開telnet，***能將此過程封裝。

這是從調用安全性來考慮。

如果從調用的簡潔性考慮，封裝亦有必要。當我們需要通過TelnetService發(fā)送telnet命令時，為何還需要了解內部的執(zhí)行邏輯呢?

那么，該如何封裝才能兩全其美，既滿足對執(zhí)行邏輯順序的重用，又滿足對命令邏輯的擴展?

通常做法是將真正的執(zhí)行邏輯提取為接口，如Java中Runnable的方式。這其實可以看作Command模式的運用。當然，我更愿意看做是對函數(shù)的封裝，例如Guva中的tranform()、filter()之類的方法，接受更具有函數(shù)氣質的Function或者Predicate接口(當時，Java 8還未問世呢)。

因此，我的做法如下：

 
 
 
    
  
  
  
  1. public class TelnetService {
    2. 
  
  
  
  2.     public T withCommand(ExecutionCommand command) {
    3. 
  
  
  
  3.         connect();
    4. 
  
  
  
  4.         login();
    5. 
  
  
  
  5.         enterUShell();
    6. 
  
  
  
  6.         T result = command.send();
    7. 
  
  
  
  7.         exitUShell();
    8. 
  
  
  
  8.         disconnect();
    9. 
  
  
  
  9.         return result;
    10. 
  
  
  
  10.     }
    11. 
  
  
  
  11. }
    12.

可以這樣調用：

 
 
 
    
  
  
  
  1. String result = telnetService.withCommand(new ExecutionCommand() {
    2. 
  
  
  
  2.         @Override
    3. 
  
  
  
  3.         public String send() {
    4. 
  
  
  
  4.             return telnetService.transfer();
    5. 
  
  
  
  5.         }
    6. 
  
  
  
  6.     }
    7. 
  
  
  
  7. );
    8.

4. 遵循異常處理的架構規(guī)則

團隊成員對異常極為陌生，面對java的受控異常、非受控異常，不知如何選擇;也不知道該何時捕獲異常，何時拋出異常。因而我針對該項目確定了異常處理的架構原則，其目的是為了讓整個架構變得更簡單，讓異常處理更加一致。

我的目的是減輕開發(fā)人員的負擔，但同時又不降低代碼質量，并利于未來對代碼的維護。規(guī)則如下：

  • 同層之間的調用不做try-catch，上層調用下層的對象，必須try-catch。即使對象拋出了異常，只要不是checked exception(我們盡量避免使用checked exception，以避免它對接口的污染)，就無需考慮去捕獲這個異常。這樣的設計并不會導致異常泄露，因為我們要求在上一層捕獲。至于最頂端的Application Layer，則只做捕獲異常的事兒，不干拋異常的活兒。
  • 為各層(即領域層和基礎設施層)定義各自的異常超類。其中，領域層定義的異常要求提供Error Code。Error Code并非我所愿，但對于本系統(tǒng)的上游系統(tǒng)，卻需要該值，不得不為。
  • 領域層。若是結合實際情況由自己拋出異常，則只需考慮異常消息和錯誤碼;若是捕獲了異常再拋出，則在捕獲時記錄日志，再度拋出的異常需要包裹原始異常對象。

在代碼診所中診斷出來的疾病，可以作為代碼評審的一個標準，同時這些處方則可以當做團隊內部分享與交流的知識庫。長期累積下來，非常有利于團隊成員編碼能力的成長。

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


網站名稱：代碼診所的第二次診斷
當前鏈接：http://www.dlmjj.cn/article/djehhco.html