老話題了，自己收集總結了一下
代碼調試排錯通常是一個痛苦的過程，至少我是這么認為的:-)。對開發人員而言，其實可以在設計和編碼時期加以控制，以提高代碼質量，
減少后期工作壓力。

下面粗略列舉一些應該注意的問題，詳細內容建議參考JTest的規則，以及DBC -- Design By Contract 規則。

JAVA設計和編碼過程中應該注意的幾個問題：

1. 不要把問題推遲到運行時刻，盡可能地在編譯時暴露問題

   這是個原則性問題，對所有的語言都是一樣的，強類型語言的出現就是這個原則的一個體現。
  
   a. 如果某個方法需要拋出異常，在方法的定義中就讓它拋出，利于編譯時檢查，否則調用者如果忘記捕獲異常，編譯時也不會得到提示，
   錯誤將延遲到運行時刻，難以調試處理。
   b. 形參的存取控制，如果不希望在方法中改變參數所引用的對象，可以用final對該參數進行限制，這樣編譯器就會幫你檢查。(其實Java
   中對參數加上final修飾并沒有什么實際用處，因為JAVA使用passed by value方式來傳遞參數，因此切記不要期望在方法內對參數賦值能
   使調用者獲得新的對象）。
   c. 避免含義模糊的參數，盡量不要為了方便而使用像Hashtable,Vector這樣含義模糊的集合類（Collection）參數來傳遞對象，除非在不
   得已的情況下才使用，但一般而言，使用抽象類的數組，以及通過良好的類層次結構設計是可以做到避免集合（Collection）類的使用的。
    
   凡事總有例外，一些模式例如工廠模式有時候需要折衷處理這個問題，為了框架代碼不至于因為子類的增加而被頻繁修改，有時候不得不把
   問題延遲到運行時刻處理。
  
2. 盡可能地在一個方法中只做一件事，如果方法實在比較復雜，盡量把它分割成合適的幾個輔助方法, 內聚和耦合的原則同樣適用于小方法
的設計，大架構，小方法可以帶給程序更好的可維護性和可測試性，同時也可以提供更多的可復用代碼，如果系統結構需要調整時，這一優勢
將會非常明顯，復雜的方法和糾纏不清的邏輯除了扔掉重來外別無它法。

  方法定義應該言行一致，方法名稱就應該完全說明這個方法是干什么的。
 
3. 接口或方法的存取控制問題，接口應該盡可能地簡單，不必讓調用者知道的方法，應該用private修飾符；提供給子類繼承的用
protected修飾，只有需要提供給外部調用的方法才允許用public，默認為包內可見但最好少用.

4. 屬性的存取控制，原則上講，除了接口的常量定義外，一般不允許使用public修飾，需要提供給子類控制的用protected,其他用
private,特別注明，默認為包內可見（有點類似C++的friendly），盡可能明確標記其訪問權限，不要含糊地使用大的范圍。

5. 使用接口還是類來定義常量， 原則上是盡量使用接口，這樣可以減少運行時的內存使用，運行時JVM可能也少耗費資源（需要確認）,
至少一個可信的理由就是JDK提供的一些內部使用的常量定義都是在接口中定義的:-)。interface中的成員和方法默認都是public, JTest
規則中對在Interface中的定義加public修飾符會報錯，個人覺得沒有必要，應該明確標記比較好。

6. 出錯時或重要邏輯點打印出盡可能詳細的信息，包括當前操作信息，一些參量的值，最好還有代碼的位置信息，很多問題難以重現，及時
捕捉并打印出詳細的調試信息有助于盡快解決故障。

7. 分開處理和集中控制的折衷， 雖然應該盡可能地按照事務或業務的需要分開處理，但對一些用來調整和控制整個系統的定義量最好集中
控制，系統的性能方面應該盡可能做到可調整的（tunable）.

8. 代碼重構  代碼重構是一個漸進的，永遠的過程，只要代碼的生命還沒有結束，就需要不斷的改進，逐步地提煉出公用的東西，將基礎支持
部分從應用中剝離出來同時就是在準備下一個應用的開發；代碼結構和邏輯逐步變得更加清晰，可維護性和可測試性也在逐步提高，更重要的是
代碼改進的同時，開發人員也在同步改進和提高。

9. Self-documented Coding 盡量在代碼中用注釋說明當前代碼的處理邏輯和一些應該注意的問題，特別是一些特殊的處理細節，除了注釋外
軟件產品的其他地方似乎沒有合適的位置保存這類信息。

10. Self-test 代碼，比較重要的單元自測代碼跟被測試代碼保存在一起比較合適，避免代碼間關系復雜化，保持單元間的獨立性

11. 盡可能少地生成對象，特別是大對象； 雖然硬件速度的提高能夠加快Java代碼的執行，但過多的使用內存使得Java程序普遍較慢，并且
經常使得系統無法同時運行其他任務。 String類使用方便，但是頻繁使用拼接（ + ）操作會帶來很多的臨時String對象，需要多次拼接形成
String時，應該考慮用StringBuffer.append()方法代替。對大系統而言，應該有可調整的策略來干預控制垃圾回收。

12. 盡可能地減少嵌套類和內部類的使用，杜絕局部類的使用，匿名類只用于監聽器（XXXListener）。

13. 不要使用太多的參數，可以考慮用一個類來封裝參數，但參數類也不能難以構造，如果出現這種問題，建議重新考慮設計是否合理。

14. 命名，盡量使用有意義的名稱來定義成員變量，方法名，常量，方法參數名稱也非常重要。

15. 文檔， JavaDoc文檔應該盡量清楚，對于提供給開發人員使用的庫，其對應JavaDoc應該詳細到開發時在集成工具中使用而不必再參考其
他文檔的程度，具體包括方法的目的，出參、入參的限制、變化，以及對類的狀態的影響，參見DBC的@pre 和@post條件。