Java程式設計師應該遵循的10條戒律

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

　　1：為程式碼新增註釋。每個人都知道這一點，但不是每個人都會這麼做。你有多少次“忘記”新增註釋了？確實，註釋不會為你的程式增加任何函式功能。但是，有多少次，看到2周前寫的程式碼，你都記不起它是幹什麼的？你很幸運，那些未註釋的程式碼是你自己寫的，你腦海中還會有殘存的印象。非常不幸，大多時候，程式碼是別人寫的，並且那個人很可能已經離開公司了。有句諺語說的好：“有來有往，互惠互利”，因此程式設計師應該體諒彼此（還有你自己），給你的程式碼加上註釋。

　　2：不要把簡單事情複雜化。我曾經這麼做過，我相信你也一樣。開發者都傾向於採用複雜方式解決簡單問題。我們在一個只有5個使用者的系統中引入EJB，為一個並不需要框架的應用實現一套框架，採用屬性檔案、採用物件導向解決方案、使用執行緒，而這些根本用不著。為什麼會這麼做？一些人可能不知道有更好的解決方案，但另一些人可能故意這樣做來學習新知識，或僅僅是因為有趣。對那些不知道更好解決方案的人，要多聽有經驗程式設計師的建議。對於那些純粹出於個人目的而將設計複雜化的人，我建議你要更加專業一點。

　　3：記住“越少越好”並非總是如此。高效率的程式碼是件好事，但很多情況下，並非程式碼行數越少效率就越高。

　　4：不要“硬編碼"。由於時間緊迫，開發者總是會忘記或故意忽略這一條。然而另一種可能是，遵循這條戒律，我們就不會陷入“時間緊迫”的困境。定義一個static final 變數，增加一行程式碼，又能花多長時間呢？

　　5：不要發明你自己的框架。不誇張地講，已經有幾千個框架存在了，大多數還是開源的。很多框架都是極完美的解決方案，並已被用到成千的系統中。我們只要關注最新的流行的框架，至少表面上要熟悉一下。一個最成功的、也是被廣泛使用的例子是Struts框架，這個開源的web框架是建立web系統的極佳選擇，不要試圖構造你自己的Struts版本，會累死的。但你必須記住第2條（譯註：原文是“第3條”，顯然不對）戒律 —— 不要把簡單事情複雜化。如果你要開發的系統只有3個介面，就不要用Struts：對於這樣一個系統，沒有足夠的需要被“控制”的東西（Struts將介面做MVC劃分，C即controller，所以作者說there isn't much "controlling" required）。

　　6：對Print行或字串說不。我知道為了除錯方便，程式設計師喜歡到處用System.out.println ,然後對自己說過一會就刪掉。但我們常常忘記刪掉這些行或不願刪掉，我們用System.out.println 做測試，為什麼測完後還要去改程式碼？這很可能導致誤刪一行我們需要的程式碼。不要低估System.out.println 的危害。

　　7：注意圖形使用者介面。無論聽上去多荒謬，但有一點我注意過多次了：圖形使用者介面（GUI）對於商業使用者而言與程式功能及執行效率一樣重要。GUI對於應用程式的成功至關重要。 IT管理者（這裡是指程式開發方的IT management）常常忽略GUI的重要性，很多公司為了省錢而不僱傭web設計人員，而這些設計人員有足夠的經驗來設計“使用者友好”的應用軟體。 Java程式設計師不得不依賴他們有限的HMTL知識。我見過非常多對“計算機友好”而非對“使用者友好”的應用程式，同時精通軟體開發和使用者介面開發的開發者非常少見。 如果你是一位不幸被指派做介面開發的Java程式設計師，你要遵循下面3條規則：

　　1）不要重新發明輪子。去看那些類似應用系統的介面。

　　2）首先建立一個原型。這一步非常關鍵。客戶喜歡提前看到他們要用的東西。同樣你可以得到他們的反饋，而不是你辛辛苦苦做出來一個客戶不喜歡的東西。

　　3）試戴使用者的帽子。換句話說，站在使用者的角度檢視需求。譬如，一個統計的介面可以分頁，也可以不分頁。作為開發者，很可能會忽略分頁，因為這會減少很多麻煩；而站在客戶角度，這就不是一個好的方案，因為資料可能多達幾百行。

　　8：提前準備需求文件。每項業務需求都記入文件。這在童話故事中可能實現，而現實中很難做到。無論時間多麼緊迫，無論截止日期如何迫近，你必須確保業務需求被記錄下來。（這條明顯悖于敏捷開發的觀念，大家要獨立思考，甄別是非）

　　9：單元測試，單元測試，單元測試。我不準備討論如何單元測試的細節，我只是想說這必須要做。這是程式設計中最基本的規則了，尤其不能忽略。如果你同事能為你的程式碼建立一個測試計劃，那就再好不過了；如果不能，那就要自己做。做單元測試計劃時，遵循下面原則：

　　1）編碼前就寫單元測試

　　2）保留單元測試的註釋

　　3）對任何“有趣的”公共方法都要做單元測試（“有趣的”是指除了像最常見的getter/setter這類方法外的方法，但包含有自己內容的getter/setter 方法）

　　10：記住：質量，而非數量。不要待的太晚（除非有必要）。有時因為產品問題，截止期限或其他突發事件，不能按時下班。但經理不會因為你為一般問題待的太晚而感激或獎勵你；他們會為有質量的工作而感激你。如果你遵循上面的列的原則，你就會寫更健壯的、少bug的程式。這才是你最應該做的。

轉自：瘋狂軟體