程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> Java開辟人員需知的十年夜戒律

Java開辟人員需知的十年夜戒律

編輯：關於JAVA

Java開辟人員需知的十年夜戒律。本站提示廣大學習愛好者：（Java開辟人員需知的十年夜戒律）文章只能為提供參考，不一定能成為您想要的結果。以下是Java開辟人員需知的十年夜戒律正文

本文講述了Java開辟人員需知的十年夜戒律。分享給年夜家供年夜家參考，詳細以下：

作為一個Java開辟人員進步本身代碼的質量，可保護性，是個長期不變的話題，網上看到這篇文章，拿來自勉。

對Java開辟者來講，有很多的尺度和最好理論。本文羅列了每個開辟人員必需服從的十年夜根本軌則；假如有了可以服從的規矩而不服從，那末將招致的是非常悲涼的終局。

1．在你的代碼裡參加正文

每一個人都曉得這點，但不知何以忘卻了遵照。算一算有若干次你“忘卻”了添加正文？這是現實：正文對法式在功效上沒有本質的進獻。然則，你須要一次又一次的回到你兩個星期之前寫的代碼下去，能夠一生都是如許，你必定記不住這些代碼為何會如許。假如這些代碼是你的，你還比擬的榮幸。由於它有能夠讓你回想起。然則不幸的是，許多時光，這些代碼是他人的，並且很有能夠他曾經分開了公司。

2．不要讓工作龐雜化

我之前就這麼干過，並且我信任一切的人都這麼干過。開辟人員經常為一個簡略的成績而提出一個處理計劃。我們為僅僅只要5個用戶的運用而引入EJBs。我們為一個運用應用框架而它基本不須要。我們參加屬性文件，面向對象的處理計劃，和線程到運用中，然則它基本不須要這些。為何我們如許做？我們中的一些人是由於不曉得怎樣做更好，然則還有一些人如許做的目標是為了進修新的常識，從而使得這個運用關於我們本身來講做得比擬風趣。

3．緊緊記住——“少等於多（less is more）”其實不永久是好的

代碼的效力是一巨大的工作，然則在許多情形下，寫更少的代碼行其實不能進步該代碼的效力。請讓我向你展現一個簡略的例子。

if(newStatusCode.equals("SD") && (sellOffDate == null || 
todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null && 
todayDate.compareTo(lastUsedDate)>0)) || 
(newStatusCode.equals("OBS") && (OBSDate == null || 
todayDate.compareTo(OBSDate)<0))){
   newStatusCode = "NYP";
}

我想問一句：說出下面的那段代碼的if前提想干甚麼輕易嗎？如今，我們再來假定不管是誰寫出這段代碼，而沒有服從第一條規矩——在你的代碼裡參加正文。
假如我們把這個前提分到兩個自力的if陳說句中，豈非不是更簡略一些嗎？如今，斟酌上面的修改代碼：

if(newStatusCode.equals("SD") && (sellOffDate == null || 
todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null && 
todayDate.compareTo(lastUsedDate)>0))){
   newStatusCode = "NYP";
}else 
if(newStatusCode.equals("OBS") && (OBSDate == null || 
todayDate.compareTo(OBSDate)<0))
{
   newStatusCode = "NYP";
}

豈非它不是有了更好的可讀性？是的，我們反復了陳說前提。是的，我們多出了一個過剩的“IF”和兩對過剩的括弧。然則代碼有了更好的可讀性和可懂得性。

4．請不要有硬代碼

開辟人員經常無意識的忘卻或許疏忽這條規矩，緣由是我們，和普通時刻一樣，在趕時光。假如我們服從這條規矩，我們能夠會趕不長進度。我們能夠不克不及停止我們確當前狀況。然則寫一條額定的界說靜態常量的代碼行又能消費我們若干時光呢？
這裡有一個例子。

public class A {
  public static final String S_CONSTANT_ABC = "ABC";
  public boolean methodA(String sParam1){
   if(A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){
 return true;
   }  
   return false;
  }
}

如今，每次我們須要和某一些變量比擬字符串“ABC”的時刻，我們只須要援用S_CONSTANT_ABC，而不是記住現實的代碼是甚麼。它還有一個利益是：加倍輕易在一個處所修正常量，而不是在一切的代碼中尋覓這個代碼。

5．不要創造你本身的frameworks

曾經推出了幾千種frameworks，並且它們中的年夜多半是開源的。這些frameworks中央有許多是極好的處理計劃，被運用到不計其數的運用中。你們須要跟上這些新frameworks的措施，最最少是浮淺的。在這些極好的、運用普遍的frameworks中央，一個最好的、最直接的例子是Struts。在你所能想象到的frameworks中，這個開源的web frameworks關於基於web的運用是一個完善的候選者。然則你必需記住第二條規矩——不要讓工作龐雜化。假如你開辟的運用只要三個頁面—請，不要應用Struts，關於如許一個運用，沒有甚麼“掌握”要求的。

6．不要打印行和字符串相加

我曉得，為了調試的目標，開辟人員愛好在每個我們以為合適的處所添加System.out.println，並且我們會對我們本身說，會在今後刪失落這些代碼的。然則我們經常忘失落刪去這些代碼行，或許我們基本就不想刪失落它們。我們應用System.out.println來測試，當我們測試完成今後，為何我們還能接觸到它們呢？我們能夠刪失落一行我們現實須要的代碼，僅僅是由於你低估了System.out.println所帶來的損害，斟酌上面的代碼：

public class BadCode {
  public static void calculationWithPrint(){
   double someValue = 0D;
   for (int i = 0; i < 10000; i++) {
 System.out.println(someValue = someValue + i);
   } 
  } 
  public static void calculationWithOutPrint(){
   double someValue = 0D;
   for (int i = 0; i < 10000; i++) {
 someValue = someValue + i;
   } 
  }
  public static void main(String [] n) {
   BadCode.calculationWithPrint();
   BadCode.calculationWithOutPrint();
  }
}

鄙人面的表格中，你可以或許看到calculationWithOutPrint()辦法的運轉花了0.001204秒。比擬較而言，運轉calculationWithPrint()辦法花了使人驚奇的10.52秒。

（假如你不曉得怎樣獲得一個像如許的表格，請參閱我的文章“Java Profiling with WSAD” Java Profiling with WSAD）
防止如許一個CPU糟蹋的最好辦法是引入一個包裝器辦法，就象上面如許

public class BadCode {
 public static final int DEBUG_MODE = 1;
 public static final int PRODUCTION_MODE = 2;
 public static void calculationWithPrint(int logMode){   
  double someValue = 0D;
  for(int i = 0; i < 10000; i++) {
   someValue = someValue + i;
   myPrintMethod(logMode, someValue);
  }
 }
 public static void myPrintMethod(int logMode, double value) {
  if (logMode > BadCode.DEBUG_MODE) { return; }
  System.out.println(value);  
 }
 public static void main(String [] n) {
   BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE);
 }
}

鄙人面的圖中，你將看到，應用了StringBuffer的誰人辦法只花了0.01秒來履行，而誰人應用了字符串相加的辦法卻花了0.08秒來運轉。選擇是不言而喻的。

7．存眷GUI

不論這聽起來有何等好笑，我都要再三地解釋：GUI關於貿易客戶來講和功效和機能一樣主要。GUI是一個勝利的體系的需要的一部門。（然則），IT雜志經常偏向於疏忽GUI的主要性。許多機構為了省錢而不招聘那些在設計“用戶友愛”GUI方面有豐碩經歷的設計人員。Java開辟人員不能不依附他們本身的HTML常識，然則他們在這方面的常識非常無限。我看到過許多如許的運用：它們是“盤算機友愛”，而不是“用戶友愛”我很少很少能看到有開辟人員既精曉軟件開辟，又精曉GUI開辟。假如你是誰人不幸的開辟人員，被分派去開辟用戶接口，你應當服從以下的三條准繩：

1、不要反復創造輪子。尋覓有類似用戶接口需求的曾經存在的體系。
2、起首創立一個原型。這長短常主要的步調。客戶愛好看看他們將要獲得甚麼。這對你來講也是很好的，由於在你盡心盡力而做出一個將要應用戶朝氣的用戶接口之前，你就獲得了它們的反應。
3、戴用戶的帽子。換一句話說，站在用戶的視角檢討運用的需求。例如，一個總結頁面究竟要不要分頁。作為一個軟件開辟者，你偏向於在一個體系中疏忽分頁，由於如許使得你有比擬少的開辟龐雜性。然則，這關於從一個用戶的視角來講卻不是最好的處理計劃，由於小結的數據將會有成百上千個數據行。

8．永久預備文檔化的需求

每個營業需求都必需文檔化。這能夠在一些童話故事裡能力成真，然則在實際世界卻弗成能。不論時光關於你的開辟來講是何等緊急，也不論交付日期立時就要到來，你永久都必需清晰，每個營業需求是文檔化的。

9．單位測試、單位測試、單位測試

我將不會深刻地評論辯論哪些甚麼是把你的代碼停止單位測試的最好辦法的細節成績。我將要說的是單位測試必需要做。這是編程的最根本的軌則。這是下面一切軌則中最不克不及被疏忽的一個。假如你的同事能為你的代碼創立和測試單位測試，這是最好不外的事。然則假如沒有工資你做這些事，那末你就必需本身做。在創立你的單位測試籌劃的時刻，服從上面的這些規矩：

1、在寫代碼之前就寫單位測試用例。
2、在單位測試裡寫正文。
3、測試一切履行“interesting”功效的私有辦法（“interesting”的意思長短setters或getters辦法，除非它們經由過程一種特別的方法履行set和get辦法）。

10．記住—質量，而不是數目。

不要在辦公室裡呆得太晚（當你不用呆的太晚的時刻）。我懂得有時，產物的成績、緊急的終究刻日、意想不到的事宜都邑阻攔我們按時上班。然則，在正常情形下，司理是不會欣賞和獎賞那些上班太晚的員工的，他欣賞他們是由於他們所做產物的質量。假如你服從了我下面給出的那些規矩，你將會發明你的代碼加倍少的bug，加倍多的可保護性。而這才是你的任務的最主要的部門。

總結

在這篇文章裡，我給出了針對Java開辟人員的十個主要的規矩。主要的不只僅是曉得這些規矩，在編碼的進程中服從這些規矩更加主要。願望這些規矩可以或許贊助我們成為更好的編程人員和專業人員。

願望本文所述對年夜家Java法式設計有所贊助。