Java法式員應當遵照的10條規律。本站提示廣大學習愛好者：（Java法式員應當遵照的10條規律）文章只能為提供參考，不一定能成為您想要的結果。以下是Java法式員應當遵照的10條規律正文
有哪些“規律”是Java法式員所要遵照的？
1. 為代碼添加正文（Add comments to your code）. – 每一個人都曉得這一點，但不是每一個人都邑這麼做。你有若干次“忘卻”添加正文了？確切，正文不會為你的法式增長任何函數功效。然則，有若干次，看到2周前寫的代碼，你都記不起它是干甚麼的？你很榮幸，那些未正文的代碼是你本身寫的，你腦海中還會有殘余的印象。異常不幸，年夜多時刻，代碼是他人寫的，而且誰人人極可能曾經分開公司了。有句諺語說的好：“有來有往，互惠互利”，是以法式員應當諒解彼此（還有你本身），給你的代碼加上正文。
2. 不要把簡略工作龐雜化（Do not complicate things）. – 我已經這麼做過，我信任你也一樣。開辟者都偏向於采取龐雜方法處理簡略成績。我們在一個只要5個用戶的體系中引入EJB，為一個其實不須要框架的運用完成一套框架，采取屬性文件、采取面向對象處理計劃、應用線程，而這些基本用不著。為何會這麼做？一些人能夠不曉得有更好的處理計劃，但另外一些人能夠有意如許做來進修新常識，或僅僅是由於風趣。對那些不曉得更好處理計劃的人，要多聽有經歷法式員的建議。關於那些純潔出於小我目標而將設計龐雜化的人，我建議你要加倍專業一點。
3. 記住 － “越少越好”並不是老是如斯(Keep in Mind – "Less is more" is not always better). – 高效力的代碼是件功德，但許多情形下，並不是代碼行數越少效力就越高。看上面這個“簡略”的例子：
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前提是甚麼有多艱苦？再假想一下，寫這段代碼的人並沒遵守第1條 － 為代碼添加正文。
把if前提分化成2個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和2個年夜括號；然則代碼確切加倍易讀、加倍輕易懂得了！
4. 不要“硬編碼"（No hard coding please）. – 因為時光緊急，開辟者老是會忘卻或有意疏忽這一條。但是另外一種能夠是，遵守這條戒律，我們就不會墮入“時光緊急”的窘境。界說一個static final 變量，增長一行代碼，又能花多長時光呢？比方：
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”與某個變量的時刻，我們只需援用 A.S_CONSTANT_ABC 便可，而不用記住它自己是甚麼。對這個常量的修正也異常便利，改一個處所便可，而不用在全體代碼中查找。
5. 不要創造你本身的框架（Do not invent your own frameworks）. – 不誇大地講，曾經有幾千個框架存在了，年夜多半照樣開源的。許多框架都是極完善的處理計劃，並已被用到成千的體系中。我們只需存眷最新的風行的框架，至多外面上要熟習一下。一個最勝利的、也是被普遍應用的例子是Struts框架，這個開源的web框架是樹立web體系的極佳選擇，不要試圖結構你本身的Struts版本，會累逝世的。但你必需記住第2條（譯注：原文是“第3條”，明顯纰謬）戒律 —— 不要把簡略工作龐雜化。假如你要開辟的體系只要3個界面，就不要用Struts. 關於如許一個體系，沒有足夠的須要被“掌握”的器械（譯注：Struts將界面做MVC劃分，C即controller，所以作者說there isn't much "controlling" required）。
6. 對Print行或字符串說不（Say no to Print lines and String Concatenations）. – 我曉得為了調試便利，法式員愛好隨處用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 s. 作為比較，calculationWithPrint() 辦法竟然須要使人難以相信的10.52 s來履行！
(若你想曉得怎樣做一個如許的表，請浏覽另外一篇文章"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);
}
}
字符串(String)銜接是另外一種CPU糟蹋方法，看上面的例子：
public static void concatenateStrings(String startingString) {
for (int i = 0; i < 20; i++) {
startingString = startingString + startingString;
}
}
public static void concatenateStringsUsingStringBuffer(
String startingString) {
StringBuffer sb = new StringBuffer();
sb.append(startingString);
for (int i = 0; i < 20; i++) {
sb.append(sb.toString());
}
}
從上面表格可以看出應用 StringBuffer只需花 0.01 s 而應用String 銜接須要0.08 s，選擇哪一種應當很顯著了。
7. 留意圖形用戶界面（Pay attention to the GUI）. – 不管聽上去多荒誕，但有一點我留意過量次了：圖形用戶界面（GUI）關於貿易用戶而言與法式功效及履行效力一樣主要。GUI關於運用法式的勝利相當主要。 IT治理者（譯注：這裡應當是指法式開辟方的IT management）經常疏忽GUI的主要性，許多公司為了省錢而不雇傭web設計人員，而這些設計人員有足夠的經歷來設計“用戶友愛”的運用軟件。 Java法式員不能不依附他們無限的HMTL常識。我見過異常多對“盤算機友愛”而非對“用戶友愛”的運用法式，同時精曉軟件開辟和用戶界面開辟的開辟者異常少見。 假如你是一名不幸被指派做界面開辟的Java法式員，你要遵守上面3條規矩：
a.不要從新創造輪子。去看那些相似運用體系的界面。
b.起首樹立一個原型。這一步異常症結。客戶愛好提早看到他們要用的器械。異樣你可以獲得他們的反應，而不是你辛辛勞苦做出來一個客戶不愛好的器械。
c.試戴用戶的帽子。換句話說，站在用戶的角度檢查需求。比方，一個統計的界面可以分頁，也能夠不分頁。作為開辟者，極可能會疏忽分頁，由於這會削減許多費事；而站在客戶角度，這就不是一個好的計劃，由於數據能夠多達幾百行。
8. 提早預備需求文檔（Always Prepare Document Requirements）. – 每項營業需求都記入文檔。這在童話故事中能夠完成，而實際中很難做到。不管時光何等緊急，不管截止日期若何逼近，你必需確保營業需求被記載上去。（譯注：這條顯著悖於迅速開辟的不雅念，年夜家要自力思慮，鑒別長短）
9. 單位測試，單位測試，單位測試 （Unit-test. Unit-test. Unit-test）. – 我禁絕備評論辯論若何單位測試的細節，我只是想說這必需要做。這是編程中最根本的規矩了，特別不克不及疏忽。假如你同事能為你的代碼創立一個測試籌劃，那就再好不外了；假如不克不及，那就要本身做。做單位測試籌劃時，遵守上面准繩：
a.編碼前就寫單位測試
b.保存單位測試的正文
c.對任何“風趣的”公共辦法都要做單位測試（“風趣的”是指除像最多見的getter/setter這類辦法外的辦法，但包括有本身內容的getter/setter 辦法）
10. 記住：質量，而非數目（Remember – quality, not quantity）. - 不要待的太晚（除非有需要）。我曉得有時由於產物成績，截止刻日或其他突發事宜，不克不及按時上班。但司理不會由於你為普通成績待的太晚而感謝或嘉獎你；他們會為有質量的任務而感謝你。假如你遵守下面的列的准繩，你就會寫更硬朗的、少bug的法式。這才是你最應當做的。
本文中總結了Java法式員最應留意的10項守則。僅僅曉得是不敷的，還要遵守它們。願望這些守則能讓我們做加倍專業的法式員。
