Java中生成檔案的10項建議

1. 記住 - "越少越好"并非總是如此（Keep in Mind – "Less is more" is not always better）。 – 高效率的代碼是件好事，但很多情況下，并非代碼行數越少效率就越高

    2. 不要把簡單事情複雜化（Do not complicate things）。 – 我曾經這麼做過，我相信你也一樣。開發者都傾向于采用複雜方式解決簡單問題。我們在一個隻有5個使用者的系統中引入EJB,為一個并不需要架構的應用實作一 套架構，采用屬性檔案、采用面向對象解決方案、使用線程，而這些根本用不着。為什麼會這麼做？一些人可能不知道有更好的解決方案，但另一些人可能故意這樣 做來學習新知識，或僅僅是因為有趣。對那些不知道更好解決方案的人，要多聽有經驗程式員的建議。對于那些純粹出于個人目的而将設計複雜化的人，我建議你要 更加專業一點。

    3. 不要"寫死"（No hard coding please）。 – 由于時間緊迫，開發者總是會忘記或故意忽略這一條。然而另一種可能是，遵循這條戒律，我們就不會陷入"時間緊迫"的困境。定義一個static final 變量，增加一行代碼，又能花多長時間呢？

    4. 為代碼添加注釋（Add comments to your code）。 – 每個人都知道這一點，但不是每個人都會這麼做。你有多少次"忘記"添加注釋了？确實，注釋不會為你的程式增加任何函數功能。但是，有多少次，看到2周前寫 的代碼，你都記不起它是幹什麼的？你很幸運，那些未注釋的代碼是你自己寫的，你腦海中還會有殘存的印象。非常不幸，大多時候，代碼是别人寫的，并且那個人 很可能已經離開公司了。有句諺語說的好："有來有往，互惠互利",是以程式員應該體諒彼此（還有你自己），給你的代碼加上注釋。

    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 的危害

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

    1. 編碼前就寫單元測試

    2.保留單元測試的注釋

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

    8. 注意圖形使用者界面（Pay attention to the GUI）。 – 無論聽上去多荒謬，但有一點我注意過多次了：圖形使用者界面（GUI）對于商業使用者而言與程式功能及執行效率一樣重要。GUI對于應用程式的成功至關重要。 IT管理者（譯注：這裡應該是指程式開發方的IT management）常常忽略GUI的重要性，很多公司為了省錢而不雇傭web設計人員，而這些設計人員有足夠的經驗來設計"使用者友好"的應用軟體。 Java程式員不得不依賴他們有限的HMTL知識。我見過非常多對"計算機友好"而非對"使用者友好"的應用程式，同時精通軟體開發和使用者界面開發的開發者 非常少見。

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

    10. 提前準備需求文檔（Always Prepare Document Requirements）。 – 每項業務需求都記入文檔。這在童話故事中可能實作，而現實中很難做到。無論時間多麼緊迫，無論截止日期如何迫近，你必須確定業務需求被記錄下來