Java Blog for Alex Wan

【收藏】Java開發(fā)者的十大戒律

原文：http://news.csdn.net/n/20071126/111088.html

有許多標(biāo)準(zhǔn)和實踐準(zhǔn)則可適用于Java開發(fā)者，但此處要說的，是每個Java開發(fā)者需堅守的基本原則。

　一、為代碼加注釋。雖然每個人都知道這點，但有時卻不自覺忘了履行，今天你“忘了”加注釋了嗎?雖然注釋對 程序的功能沒什么“貢獻”，但過一段時間，比如說兩星期之后或者更長，回過頭來看看自己的代碼，說不定已經(jīng)記不住它是干什么的了。如果這些代碼是你個人 的，那還算是走運了，不幸的是，當(dāng)然了，大多數(shù)時候都是別人的不幸，很多時候大家都是在為公司寫代碼，寫代碼的人也許早已經(jīng)離開了公司，但別忘了一句古 話，有來有往嘛，為他人，也為我們自己，請為你的代碼加上注釋。

二、不要讓事情復(fù)雜化。程序員有時候總是對簡單問題想出復(fù)雜的解決方案，比如說，在只有五個用戶的程序中引 入EJB、對程序?qū)崿F(xiàn)了并不需要的框架(framework)，之類的還有屬性文件、面向?qū)ο蠼鉀Q方案、多線程等等。為什么要這樣做呢?也許我們并不知道 是否這樣會更好，但這樣做也許可以學(xué)到一些新東西，或者讓自己更感興趣一些。如果是不知道為什么這樣做，建議多請教經(jīng)驗豐富的程序員，如果是為了個人的目 的，麻煩讓自己更專業(yè)一點。

　　三、始終牢記——“少即是好(Less is more)并不總是對的”。代碼效率雖然很重要，但在許多解決方案中，編寫更少的代碼并不能改善這些代碼的效率，請看下面這個簡單的例子：

能看明白if條件語句是干什么的嗎?能想出來是誰寫的這段代碼嗎?如果把它分成兩段獨立的if語句，是不是更容易理解呢，下面是修改后的代碼：

是不是讀起來容易多了呢，在此只是多加了一個if和兩個花括號，但代碼的可讀性與可理解性就一下子提高了一大截。

　　四、請不要硬編碼。開發(fā)者經(jīng)常有意“忘記”或忽略掉這點，因為有些時候開發(fā)日程逼得實在太緊。其實，多寫一行定義靜態(tài)變量的代碼能花多少時間呢?

現(xiàn)在，每次需要將“ABC”與其他變量進行比較時，不必記住實際代碼，直接引用A.S_CONSTANT_ABC就行了，而且在今后需要進行修改時，也可在一處修改，不會翻遍整個源代碼逐個修改了。

　　五、不要“創(chuàng)造”自己的框架(framework)。確切來說，有數(shù)以千計的各種框架存在，而且大多數(shù)是開 源的，這些框架都是優(yōu)秀的解決方案，可用于日常程序開發(fā)中，我們只需使用這些框架的最新版本就行了，至少表面上要跟上形勢吧。被大家廣為接受的最為明顯的 一個例子就是Struts了，這個開源web框架非常適合用在基于web的應(yīng)用程序中。是不是想開發(fā)出自己的Struts呢，還是省點力氣吧，回頭看看第 二條——不要讓事情復(fù)雜化。另外，如果正在開發(fā)的程序只有3個窗口，就不要使用Struts了，對這種程序來說，不需要那么多的“控制”。

　　六、不要使用println及字符串連接。通常為了調(diào)試方便，開發(fā)者喜歡在可能的所有地方都加上 System.out.println，也許還會提醒自己回過頭來再來刪除，但有些時候，經(jīng)常會忘了刪除或者不愿意刪除它們。既然使用 System.out.println是為了測試，那么測試完之后，為什么還要留著它們呢，因為在刪除時，很可能會刪除掉真正有用的代碼，所以不能低估 System.out.println危害啊，請看下面的代碼：

從測試中可以發(fā)現(xiàn)，方法calculationWithOutPrint()執(zhí)行用了0.001204秒，作為對比，方法calculationWithPrint()執(zhí)行可是用了10.52秒。

　　要避免浪費CPU時間，最好的方法是引入像如下的包裝方法：

另外，字符串連接也是浪費CPU時間的一個大頭，請看下面的示例代碼：
在測試中可發(fā)現(xiàn)，使用StringBuffer的方法只用了0.01秒執(zhí)行完畢，而使用連接的方法則用了0.08秒，選擇顯而易見了。

　　七、多關(guān)注GUI(用戶界面)。再三強調(diào)，GUI對商業(yè)客戶來說，與程序的功能及效率同等重要，GUI是一 個成功程序的最基本部分，而很多IT經(jīng)理往往都沒注意到GUI的重要性。在現(xiàn)實生活中，許多公司可能為了節(jié)省開支，沒有雇用那些有著設(shè)計“用戶友好”界面 豐富經(jīng)驗的網(wǎng)頁設(shè)計者，此時Java開發(fā)者只能依賴他們自身的HTML基本功及在此領(lǐng)域有限的知識，結(jié)果，很多開發(fā)出來的程序都是“計算機友好”甚于“用 戶友好”。很少有開發(fā)者同時精通軟件開發(fā)及GUI設(shè)計，如果你在公司“不幸”被分配負責(zé)程序界面，就應(yīng)該遵守下面三條原則：

　　1、 不要再發(fā)明一次輪子，即不做無用功。現(xiàn)有的程序可能會有類似的界面需求。

　　2、 先創(chuàng)建一個原型。這是非常重要一步，用戶一般想看到他們將使用的東西，而且可以先利用這個原型征求用戶的意見，再慢慢修改成用戶想要的樣子。

　　3、 學(xué)會換位思考。換句話來說，就是從用戶的角度來審查程序的需求。舉例來講，一個匯總的窗口可以跨頁或者不跨頁，作為一個軟件開發(fā)者，可能會傾向于不跨頁，因為這樣簡單一些。但是，從用戶的角度來看，可能不希望看到上百行數(shù)據(jù)都擠在同一頁上。

　　八、文檔需求不放松。每個商業(yè)需求都必須記錄在案，這可能聽上去像童話，似乎在現(xiàn)實生活中很難實現(xiàn)。而我們要做的是，不管開發(fā)時間多緊迫，不管最終期限多臨近，對每個商業(yè)需求都必須記錄在案。

　　九、單元測試、單元測試、單元測試。關(guān)于什么是單元測試的最好方法，在此不便細說，只是強調(diào)，單元測試一定要完成，這也是編程中最基本的原則。當(dāng)然了，如果有人幫你做單元測試自然是最好，如果沒有，就自己來做吧，當(dāng)創(chuàng)建一個單元測試計劃時，請遵守以下三條最基本的原則：

　　1、 先于編寫類代碼之前編寫單元測試。

　　2、 記錄單元測試中的代碼注釋。

　　3、 測試所有執(zhí)行關(guān)鍵功能的公有方法，這里不是指set和get方法，除非它們是以自己獨特方式執(zhí)行set和get方法。

　　十、質(zhì)量，而不是數(shù)量。有些時候因為產(chǎn)品問題、期限緊迫、或一些預(yù)料之外的事情，導(dǎo)致常常不能按時下班，但一般而言，公司不會因為雇員經(jīng)常加班而對之表揚和獎勵，公司只看重高質(zhì)量的工作。如果遵守了前九條原則，你會發(fā)現(xiàn)自己寫出的代碼bug少且可維護性高，無形中質(zhì)量提高了一大步。

Let life be beautiful like summer flowers and death like autumn leaves.

posted on 2008-06-07 10:09 Alexwan 閱讀(198) 評論(0)  編輯  收藏 所屬分類: 好文分享