Java開發(fā)者需要注意的十條法則
1.給你的代碼加注解—每個(gè)人都知道這一點(diǎn),但是總會(huì)有人忘記遵守。你有多少次“忘記”加注解了?的卻不加文字注解有助于程序的功能性。但是一次又一你返回兩星期前寫的代碼,結(jié)果你想不起來那是什么了!如果這個(gè)未注解的代碼確實(shí)是你寫的那你就是幸運(yùn)的了。因?yàn)樵谀切┐a中可以喚起你的記憶。不幸的是,大多數(shù)的時(shí)候代碼是別人寫的,而且他已將離開了公司!有句諺語是這樣說的“自己的事情自己做”。所以為了別人或是我們自己考慮,在你的代碼上加上注解吧。
2.別把事情復(fù)雜化— 我以前就是這么做的而其我相信你們也一樣。開發(fā)者喜歡把簡(jiǎn)單的問題用很復(fù)雜的方法來解決。我們介紹EJBs到有五個(gè)用戶的應(yīng)用程序中。我們完成一個(gè)框架結(jié)構(gòu)那是應(yīng)用程序所不需要的。我們添加屬性文件,目標(biāo)源方案到本不需要這些東西的應(yīng)用程序中。為什么我們要這樣做呢?一些人是不知道如何去做,而一些人故意這么做是想去學(xué)習(xí)新的東西,想讓我們感興趣。對(duì)于那些不知道如何去做的人,我建議去向經(jīng)驗(yàn)豐富的編程人員去詢問。而對(duì)于那些喜歡把應(yīng)用程序設(shè)計(jì)搞復(fù)雜的人,我的建議還是要更專業(yè)一些來處理問題。
3.記住—“少即是多”不見得是件好事?!?/STRONG>代碼效率是件非常好的事情,但是很多情況下少寫幾行代碼并不能提高代碼工作的效率。舉個(gè)簡(jiǎn)單的例子:
if(newStatusCode.equals("SD") && (sellOffDate == null || |
查出“if”條件下在做什么是多么簡(jiǎn)單的事情?現(xiàn)在想象一下寫這個(gè)代碼的人,沒有遵守第一個(gè)規(guī)則-給代碼加注解 。如果我們把這個(gè)情況分成兩個(gè)獨(dú)立的if語句豈不是更簡(jiǎn)單一些么?現(xiàn)在看一下修改后的代碼:
if(newStatusCode.equals("SD") && (sellOffDate == null || |
是不是更清晰了?是的,我們?cè)谥貜?fù)一下。我們有另一個(gè)“IF” 和兩個(gè)額外的括號(hào),但是這個(gè)代碼更容易讀懂了!
4.不要有難懂的代碼—開發(fā)者經(jīng)常忘記這一點(diǎn)或是忽略故意忽略這條規(guī)則,因?yàn)橥ǔN覀兌荚谮s時(shí)間。但是如果我們能遵守這個(gè)規(guī)則,我們就不會(huì)終止我們所處的形勢(shì)了。要花多長(zhǎng)時(shí)間去寫入另外一行最后定義的靜態(tài)變量代碼呢?
舉個(gè)例子:
public class A { |
現(xiàn)在每當(dāng)我們需要文字“ABC”和一些變量作比較,我們可以參考A.S_CONSTANT_ABC而不是回憶實(shí)際的代碼是什么。在一個(gè)地方不斷的修改要比在所有代碼中尋找要容易得多。
5.不要發(fā)明自己的框架結(jié)構(gòu)—有數(shù)以千計(jì)的框架結(jié)構(gòu)而其大多數(shù)都是開放源。許多框架結(jié)構(gòu)是被用在數(shù)以千計(jì)的應(yīng)用程序中的優(yōu)秀的解決方案。至少在表面我們需要用上新的框架結(jié)構(gòu)。其中最好的也是廣發(fā)應(yīng)用的框架結(jié)構(gòu)的例子就是Struts。這個(gè)開放源web結(jié)果框架是一個(gè)非常好的候選者來用于web-based應(yīng)用程序。請(qǐng)不要用自己版本的Strut,你將會(huì)在嘗試中死去。但是你必須記住規(guī)則2—?jiǎng)e把事情復(fù)雜化。如果你的應(yīng)用程序要開發(fā)3個(gè)screen-請(qǐng)不要用Struts,目前還沒有像這樣的應(yīng)用程序的“控制”需求。
6.要對(duì)打印線和字符串串聯(lián)說“不”—我知道在以調(diào)試為目,開發(fā)者喜歡到處在我們覺得適合的地方添加System.out.println。又自言自語的說一會(huì)兒我們會(huì)刪除這些的。但是我們總是忘記刪除這些代碼行或者不想去刪除它們。我們用System.out.println來進(jìn)行測(cè)試,為什么我們?cè)跍y(cè)試完成后才觸及這些代碼呢?我們可能會(huì)刪除一行代碼當(dāng)我們確實(shí)要這么做的時(shí)候!只要你不要低估System.out.println 的破壞,看以下的代碼:
public class BadCode { |
在上面所顯示的,你能觀察到calculationWithOutPrint()用了0.001204秒運(yùn)行。相比之下,用了驚人的10.52秒去運(yùn)行calculationWithPrint() method。
(如果你想要知道如何制作這個(gè)的表格,請(qǐng)閱讀我的文章題目是"Java Profiling with WSAD" Java Profiling with WSAD)
最好的像避免CPU浪費(fèi)的方法是去引用像這樣的包裝方法:
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 concatenation is another CPU waster. Consider example below:
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());}}
在以下的數(shù)據(jù)中能看到該方法用StringBuffer花了.01秒去執(zhí)行而同時(shí)用字符串串聯(lián)的方法用了.08秒去執(zhí)行。選擇是很明顯的。
7.關(guān)注GUI—無論聽起來有多么荒謬,我要一再指出的是GUI的功能和運(yùn)行情況和商業(yè)客戶是同等重要的。GUI是一個(gè)成功的應(yīng)用程序的重要組成部分。IT管理總是忽略GUI的重要性。許多機(jī)構(gòu)省錢的方式是不雇用設(shè)計(jì)“user-friendly”應(yīng)用程序有經(jīng)驗(yàn)的網(wǎng)絡(luò)設(shè)計(jì)師。Java開發(fā)者不得不依賴于他們自己的HTML技術(shù)和在此領(lǐng)域的那點(diǎn)局限性知識(shí)。我見過太多的應(yīng)用程序是 “computer friendly”而不是 “ user friendly”。很少看到有開發(fā)者在軟件開發(fā)和GUI開發(fā)兩者都同樣精通的。如果你是那個(gè)不幸的被指定去創(chuàng)建一個(gè)應(yīng)用程序界面的Java開發(fā)者,你可以遵循這三個(gè)規(guī)則:
1. 不要重新發(fā)明車輪。尋找現(xiàn)有的有類似接口需求的應(yīng)用程序。
2. 先創(chuàng)建個(gè)雛形。這是非常重要的步驟??蛻粝胍吹剿麄兡艿玫叫┦裁础_@樣對(duì)你來說是有意的,是因?yàn)樵谀闳σ愿肮ぷ髦翱梢缘玫娇蛻舻囊蟛⑶铱梢詣?chuàng)建一個(gè)應(yīng)用程序界面,這樣可以讓客戶冷靜下來。
3. 帶上用戶的帽子。換句話說,就是需要從用戶的角度來檢查應(yīng)用程序的需求。例如,一個(gè)總結(jié)性的screen可以用標(biāo)頁的方式來創(chuàng)建。作為一個(gè)軟件開發(fā)人員,允許從應(yīng)用程序中忽略標(biāo)記很讓人惱火,因?yàn)樗_實(shí)有一點(diǎn)復(fù)雜。但是,從客戶的角度來看,可能不是很好的解決方案,因?yàn)榭偨Y(jié)的結(jié)果可以容納數(shù)百個(gè)數(shù)據(jù)行。
8. 時(shí)刻準(zhǔn)備文件需求— 每一商業(yè)需求都要記錄在案。這個(gè)在一些童話故事里是正確的,但是遠(yuǎn)離了現(xiàn)實(shí)世界。無論你的開發(fā)有多么的時(shí)間緊迫,無論你的最后期限要求的多么嚴(yán)格,你必須確保每個(gè)商業(yè)需求都是被記錄在案的。
9.單元測(cè)試。單元測(cè)試,單元測(cè)試—我就不詳細(xì)的說明什么是做你的代碼單元測(cè)試的最好方法。我只是想說的是必須要這么做。這是編程中最基本的規(guī)則。這是一個(gè)首先就不能被忽視的規(guī)則。如果你的下一個(gè)開發(fā)人員可以創(chuàng)建并為你的代碼執(zhí)行測(cè)試計(jì)劃,那是在是太棒了。但是如果不可能,那你必須自己來做。建立一個(gè)單元測(cè)試計(jì)劃,遵循以下這些基本規(guī)則:
1. 在寫代碼之前為分類測(cè)試寫一個(gè)單元測(cè)試計(jì)劃。
2. 在單元測(cè)試中獲取代碼注解。
3. 執(zhí)行一個(gè)“有趣的”功能測(cè)試所有的公開的方法(也就是說,沒有獲得者和設(shè)置者,除非他們用一些獨(dú)特方法來進(jìn)行他們的獲取和設(shè)置。)
10. 記住—質(zhì)量,不是數(shù)量—不要呆得太晚(如果你不需要這么做)。我理解有時(shí)候產(chǎn)品問題,緊迫的最后期限和不希望發(fā)生的一些事情會(huì)阻止我們不能按時(shí)離開工作崗位。但是,經(jīng)理們是不會(huì)感謝和報(bào)答他們的員工因?yàn)樗麄兛偸谴舻脮r(shí)間太長(zhǎng),他們感謝員工是因?yàn)樗麄冏隽烁哔|(zhì)量的工作。如果你遵循以上所提到的這些規(guī)則,你將會(huì)發(fā)現(xiàn)你產(chǎn)生很少的bug,獲得更多的可維護(hù)的代碼。這是你工作中最重要的部分。
【編輯推薦】

























