程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> Java程序員應該遵循的10條戒律

Java程序員應該遵循的10條戒律

編輯:關於JAVA

Java程序員有許多應遵循的守則或最佳實踐方式。本文概述了每個開發者最應該遵循的10條守則或戒律,如果不遵循它們,將會導致災難性後果。

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). – 高效率的代碼是件好事,但很多情況下,並非代碼行數越少效率就越高。看下面這個“簡單”的例子:

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

指出這個if條件是什麼有多困難?再設想一下,寫這段代碼的人並沒遵循第1條 - 為代碼添加注釋。

把if條件分解成2個if語句不是更容易理解嗎?現在讓我們看一下修改過的代碼:

  1. if(newStatusCode.equals("SD") && (sellOffDate == null ||
  2. todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null &&
  3. todayDate.compareTo(lastUsedDate)>0))){
  4. newStatusCode = "NYP";
  5. }else
  6. if(newStatusCode.equals("OBS") && (OBSDate == null ||
  7. todayDate.compareTo(OBSDate)<0))
  8. {
  9. newStatusCode = "NYP";
  10. }

這樣可讀性不是更好嗎?的確,我們寫了重復語句;的確,我們多寫了一個if和2個大括號;但是代碼確實更加易讀、更加容易理解了!

4. 不要“硬編碼"(No hard coding please). – 由於時間緊迫,開發者總是會忘記或故意忽略這一條。然而另一種可能是,遵循這條戒律,我們就不會陷入“時間緊迫”的困境。定義一個static final 變量,增加一行代碼,又能花多長時間呢?譬如:

  1. public class A {
  2. public static final String S_CONSTANT_ABC = "ABC";
  3. public boolean methodA(String sParam1){
  4. if (A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){
  5. return true;
  6. }
  7. return false;
  8. }
  9. }

現在,每次需要比較字符串“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 的危害,看下面代碼:

  1. public class BadCode {
  2. public static void calculationWithPrint(){
  3. double someValue = 0D;
  4. for (int i = 0; i < 10000; i++) {
  5. System.out.println(someValue = someValue + i);
  6. }
  7. }
  8. public static void calculationWithOutPrint(){
  9. double someValue = 0D;
  10. for (int i = 0; i < 10000; i++) {
  11. someValue = someValue + i;
  12. }
  13. }
  14. public static void main(String [] n) {
  15. BadCode.calculationWithPrint();
  16. BadCode.calculationWithOutPrint();
  17. }
  18. }

下面表格可以看出,calculationWithOutPrint() 方法執行時間是0.001204 s. 作為對比,calculationWithPrint() 方法居然需要令人難以置信的10.52 s來執行!

(若你想知道怎麼做一個這樣的表,請閱讀另一篇文章"Java Profiling with WSAD" Java Profiling with WSAD )

為了避免CPU浪費,最好的辦法是引入一個包裝的方法,如下:

  1. public class BadCode {
  2. public static final int DEBUG_MODE = 1;
  3. public static final int PRODUCTION_MODE = 2;
  4. public static void calculationWithPrint(int logMode){
  5. double someValue = 0D;
  6. for (int i = 0; i < 10000; i++) {
  7. someValue = someValue + i;
  8. myPrintMethod(logMode, someValue);
  9. }
  10. }
  11. public static void myPrintMethod(int logMode, double value) {
  12. if (logMode > BadCode.DEBUG_MODE) { return; }
  13. System.out.println(value);
  14. }
  15. public static void main(String [] n) {
  16. BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE);
  17. }
  18. }

字符串(String)連接是另一種CPU浪費方式,看下面的例子:

  1. public static void concatenateStrings(String startingString) {
  2. for (int i = 0; i < 20; i++) {
  3. startingString = startingString + startingString;
  4. }
  5. }
  6. public static void concatenateStringsUsingStringBuffer(
  7. String startingString) {
  8. StringBuffer sb = new StringBuffer();
  9. sb.append(startingString);
  10. for (int i = 0; i < 20; i++) {
  11. sb.append(sb.toString());
  12. }
  13. }

從下面表格可以看出使用 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條規則:

  1. 不要重新發明輪子。去看那些類似應用系統的界面。
  2. 首先建立一個原型。這一步非常關鍵。客戶喜歡提前看到他們要用的東西。同樣你可以得到他們的反饋,而不是你辛辛苦苦做出來一個客戶不喜歡的東西。
  3. 試戴用戶的帽子。換句話說,站在用戶的角度查看需求。譬如,一個統計的界面可以分頁,也可以不分頁。作為開發者,很可能會忽略分頁,因為這會減少很多麻煩;而站在客戶角度,這就不是一個好的方案,因為數據可能多達幾百行。

8. 提前准備需求文檔(Always Prepare Document Requirements). – 每項業務需求都記入文檔。這在童話故事中可能實現,而現實中很難做到。無論時間多麼緊迫,無論截止日期如何迫近,你必須確保業務需求被記錄下來。(譯注:這條明顯悖於敏捷開發的觀念,大家要獨立思考,甄別是非)

9. 單元測試,單元測試,單元測試 (Unit-test. Unit-test. Unit-test). – 我不准備討論如何單元測試的細節,我只是想說這必須要做。這是編程中最基本的規則了,尤其不能忽略。如果你同事能為你的代碼創建一個測試計劃,那就再好不過了;如果不能,那就要自己做。做單元測試計劃時,遵循下面原則:

  1. 編碼前就寫單元測試
  2. 保留單元測試的注釋
  3. 對任何“有趣的”公共方法都要做單元測試(“有趣的”是指除了像最常見的getter/setter這類方法外的方法,但包含有自己內容的getter/setter 方法)

10. 記住:質量,而非數量(Remember – quality, not quantity). - 不要待的太晚(除非有必要)。我知道有時因為產品問題,截止期限或其他突發事件,不能按時下班。但經理不會因為你為一般問題待的太晚而感激或獎勵你;他們會為有質量的工作而感激你。如果你遵循上面的列的原則,你就會寫更健壯的、少bug的程序。這才是你最應該做的。

結論

本文中總結了Java程序員最應注意的10項守則。僅僅知道是不夠的,還要遵循它們。希望這些守則能讓我們做更加專業的程序員。

不是每個人都能成為高手,但是不努力,就算有再高的天分,也白癡一個!

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved