由于移動互聯網的方興未艾，作為移動互聯網開發的重要組成部分，Java開發目前也是行業當中的熱門。那么在Java開發過程中，開發者應該注意哪些問題呢？中培偉業《JAVA高級開發技術實戰》課程培訓專家程老師在這里為大家詳細進行介紹。

1． 在你的代碼里加入注釋

每個人都知道這點，但不知何故忘記了遵守。算一算有多少次你“忘記”了添加注釋？這是事實：注釋對程序在功能上沒有實質的貢獻。但是，你需要一次又一次的回到你兩個禮拜之前寫的代碼上來，可能一輩子都是這樣，你一定記不住這些代碼為什么會這樣。如果這些代碼是你的，你還比較的幸運。因為它有可能讓你回憶起。但是不幸的是，很多時間，這些代碼是別人的，而且很有可能他已經離開了公司。

2． 不要讓事情復雜化

我以前就這么干過，而且我相信所有的人都這么干過。開發人員常常為一個簡單的問題而提出一個解決方案。我們為僅僅只有5個用戶的應用而引入EJBs。我們為一個應用使用框架而它根本不需要。我們加入屬性文件，面向對象的解決方案，和線程到應用中，但是它根本不需要這些。為什么我們這樣做？我們中的一些人是因為不知道怎么做更好，但是還有一些人這樣做的目的是為了學習新的知識，從而使得這個應用對于我們自己來說做得比較有趣。

3． 牢牢記住——“少即是多（less is more）”并不永遠是好的

代碼的效率是一偉大的事情，但是在很多情況下，寫更少的代碼行并不能提高該代碼的效率。說出上面的那段代碼的if條件想干什么容易嗎？現在，我們再來假設無論是誰寫出這段代碼，而沒有遵從第一條規則——在你的代碼里加入注釋。

如果我們把這個條件分到兩個獨立的if陳述句中，難道不是更簡單一些嗎？

難道它不是有了更好的可讀性？是的，我們重復了陳述條件。是的，我們多出了一個多余的“IF”和兩對多余的括弧。但是代碼有了更好的可讀性和可理解性。

4． 請不要有硬代碼

開發人員常常有意識的忘記或者忽視這條規則，原因是我們，和一般時候一樣，在趕時間。如果我們遵從這條規則，我們可能會趕不上進度。我們可能不能結束我們的當前狀態。但是寫一條額外的定義靜態常量的代碼行又能花費我們多少時間呢？

現在，每一次我們需要和某一些變量比較字符串“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所帶來的傷害。

7． 關注GUI

不管這聽起來有多么可笑，我都要再三地說明：GUI對于商業客戶來說和功能和性能一樣重要。GUI是一個成功的系統的必要的一部分。（但是），IT雜志常常傾向于忽視GUI的重要性。很多機構為了省錢而不雇用那些在設計“用戶友好”GUI方面有豐富經驗的設計人員。Java開發人員不得不依賴他們自己的HTML知識，但是他們在這方面的知識十分有限。我看到過很多這樣的應用：它們是“計算機友好”，而不是“用戶友好”我很少很少能看到有開發人員既精通軟件開發，又精通GUI開發。如果你是那個不幸的開發人員，被分配去開發用戶接口，你應該遵從以下的三條原則：

（一）、不要重復發明輪子。尋找有相似用戶接口需求的已經存在的系統。

（二）、首先創建一個原型。這是非常重要的步驟?？蛻粝矚g看看他們將要得到什么。這對你來說也是很好的，因為在你全力以赴而做出一個將要使用戶生氣的用戶接口之前，你就得到了它們的反饋。

（三）、戴用戶的帽子。換一句話說，站在用戶的視角檢查應用的需求。例如，一個總結頁面到底要不要分頁。作為一個軟件開發者，你傾向于在一個系統中忽視分頁，因為這樣使得你有比較少的開發復雜性。但是，這對于從一個用戶的視角來說卻不是最好的解決方案，因為小結的數據將會有成百上千個數據行。

8． 永遠準備文檔化的需求

每一個業務需求都必須文檔化。這可能在一些童話故事里才能成真，但是在現實世界卻不可能。不管時間對于你的開發來說是多么緊迫，也不管交付日期馬上就要到來，你永遠都必須清楚，每一個業務需求是文檔化的。

9． 單元測試、單元測試、單元測試

我將不會深入地討論哪些什么是把你的代碼進行單元測試的最佳方法的細節問題。我將要說的是單元測試必須要做。這是編程的最基本的法則。這是上面所有法則中最不能被忽略的一個。如果你的同事能為你的代碼創建和測試單元測試，這是最好不過的事。但是如果沒有人為你做這些事，那么你就必須自己做。在創建你的單元測試計劃的時候，遵從下面的這些規則：

（一）、在寫代碼之前就寫單元測試用例。

（二）、在單元測試里寫注釋。

（三）、測試一切執行“interesting”功能的公有方法（“interesting”的意思是非setters或getters方法，除非它們通過一種特殊的方式執行set和get方法）。

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

不要在辦公室里呆得太晚（當你不必呆的太晚的時候）。我理解有時，產品的問題、緊迫的最終期限、意想不到的事件都會阻止我們按時下班。但是，在正常情況下，經理是不會賞識和獎賞那些下班太晚的員工的，他賞識他們是因為他們所做產品的質量。如果你遵從了我上面給出的那些規則，你將會發現你的代碼更加少的bug，更加多的可維護性。而這才是你的工作的最重要的部分。