小李飛刀 閱讀(193) 評(píng)論(0) ?編輯 ?收藏

老話題了，自己收集總結(jié)了一下

代碼調(diào)試排錯(cuò)通常是一個(gè)痛苦的過程，至少我是這么認(rèn)為的:-)。對(duì)開發(fā)人員而言，其實(shí)可以在設(shè)計(jì)和編碼時(shí)期加以控制，以提高代碼質(zhì)量，

減少后期工作壓力。

下面粗略列舉一些應(yīng)該注意的問題，詳細(xì)內(nèi)容建議參考JTest的規(guī)則，以及DBC -- Design By Contract 規(guī)則。

JAVA設(shè)計(jì)和編碼過程中應(yīng)該注意的幾個(gè)問題：

1. 不要把問題推遲到運(yùn)行時(shí)刻，盡可能地在編譯時(shí)暴露問題

這是個(gè)原則性問題，對(duì)所有的語言都是一樣的，強(qiáng)類型語言的出現(xiàn)就是這個(gè)原則的一個(gè)體現(xiàn)。

a. 如果某個(gè)方法需要拋出異常，在方法的定義中就讓它拋出，利于編譯時(shí)檢查，否則調(diào)用者如果忘記捕獲異常，編譯時(shí)也不會(huì)得到提示，

錯(cuò)誤將延遲到運(yùn)行時(shí)刻，難以調(diào)試處理。

b. 形參的存取控制，如果不希望在方法中改變參數(shù)所引用的對(duì)象，可以用final對(duì)該參數(shù)進(jìn)行限制，這樣編譯器就會(huì)幫你檢查。(其實(shí)Java

中對(duì)參數(shù)加上final修飾并沒有什么實(shí)際用處，因?yàn)镴AVA使用passed by value方式來傳遞參數(shù)，因此切記不要期望在方法內(nèi)對(duì)參數(shù)賦值能

使調(diào)用者獲得新的對(duì)象)。

c. 避免含義模糊的參數(shù)，盡量不要為了方便而使用像Hashtable,Vector這樣含義模糊的集合類(Collection)參數(shù)來傳遞對(duì)象，除非在不

得已的情況下才使用，但一般而言，使用抽象類的數(shù)組，以及通過良好的類層次結(jié)構(gòu)設(shè)計(jì)是可以做到避免集合(Collection)類的使用的。

凡事總有例外，一些模式例如工廠模式有時(shí)候需要折衷處理這個(gè)問題，為了框架代碼不至于因?yàn)樽宇惖脑黾佣活l繁修改，有時(shí)候不得不把

問題延遲到運(yùn)行時(shí)刻處理。

2. 盡可能地在一個(gè)方法中只做一件事，如果方法實(shí)在比較復(fù)雜，盡量把它分割成合適的幾個(gè)輔助方法, 內(nèi)聚和耦合的原則同樣適用于小方法

的設(shè)計(jì)，大架構(gòu)，小方法可以帶給程序更好的可維護(hù)性和可測(cè)試性，同時(shí)也可以提供更多的可復(fù)用代碼，如果系統(tǒng)結(jié)構(gòu)需要調(diào)整時(shí)，這一優(yōu)勢(shì)

將會(huì)非常明顯，復(fù)雜的方法和糾纏不清的邏輯除了扔掉重來外別無它法。

方法定義應(yīng)該言行一致，方法名稱就應(yīng)該完全說明這個(gè)方法是干什么的。

3. 接口或方法的存取控制問題，接口應(yīng)該盡可能地簡單，不必讓調(diào)用者知道的方法，應(yīng)該用private修飾符；提供給子類繼承的用

protected修飾，只有需要提供給外部調(diào)用的方法才允許用public，默認(rèn)為包內(nèi)可見但最好少用.

4. 屬性的存取控制，原則上講，除了接口的常量定義外，一般不允許使用public修飾，需要提供給子類控制的用protected,其他用

private,特別注明，默認(rèn)為包內(nèi)可見(有點(diǎn)類似C++的friendly)，盡可能明確標(biāo)記其訪問權(quán)限，不要含糊地使用大的范圍。

5. 使用接口還是類來定義常量， 原則上是盡量使用接口，這樣可以減少運(yùn)行時(shí)的內(nèi)存使用，運(yùn)行時(shí)JVM可能也少耗費(fèi)資源(需要確認(rèn)),

至少一個(gè)可信的理由就是JDK提供的一些內(nèi)部使用的常量定義都是在接口中定義的:-)。interface中的成員和方法默認(rèn)都是public, JTest

規(guī)則中對(duì)在Interface中的定義加public修飾符會(huì)報(bào)錯(cuò)，個(gè)人覺得沒有必要，應(yīng)該明確標(biāo)記比較好。

6. 出錯(cuò)時(shí)或重要邏輯點(diǎn)打印出盡可能詳細(xì)的信息，包括當(dāng)前操作信息，一些參量的值，最好還有代碼的位置信息，很多問題難以重現(xiàn)，及時(shí)

捕捉并打印出詳細(xì)的調(diào)試信息有助于盡快解決故障。

7. 分開處理和集中控制的折衷， 雖然應(yīng)該盡可能地按照事務(wù)或業(yè)務(wù)的需要分開處理，但對(duì)一些用來調(diào)整和控制整個(gè)系統(tǒng)的定義量最好集中

控制，系統(tǒng)的性能方面應(yīng)該盡可能做到可調(diào)整的(tunable).

8. 代碼重構(gòu)? 代碼重構(gòu)是一個(gè)漸進(jìn)的，永遠(yuǎn)的過程，只要代碼的生命還沒有結(jié)束，就需要不斷的改進(jìn)，逐步地提煉出公用的東西，將基礎(chǔ)支持

部分從應(yīng)用中剝離出來同時(shí)就是在準(zhǔn)備下一個(gè)應(yīng)用的開發(fā)；代碼結(jié)構(gòu)和邏輯逐步變得更加清晰，可維護(hù)性和可測(cè)試性也在逐步提高，更重要的是

代碼改進(jìn)的同時(shí)，開發(fā)人員也在同步改進(jìn)和提高。

9. Self-documented Coding 盡量在代碼中用注釋說明當(dāng)前代碼的處理邏輯和一些應(yīng)該注意的問題，特別是一些特殊的處理細(xì)節(jié)，除了注釋外

軟件產(chǎn)品的其他地方似乎沒有合適的位置保存這類信息。

10. Self-test 代碼，比較重要的單元自測(cè)代碼跟被測(cè)試代碼保存在一起比較合適，避免代碼間關(guān)系復(fù)雜化，保持單元間的獨(dú)立性

11. 盡可能少地生成對(duì)象，特別是大對(duì)象； 雖然硬件速度的提高能夠加快Java代碼的執(zhí)行，但過多的使用內(nèi)存使得Java程序普遍較慢，并且

經(jīng)常使得系統(tǒng)無法同時(shí)運(yùn)行其他任務(wù)。 String類使用方便，但是頻繁使用拼接( + )操作會(huì)帶來很多的臨時(shí)String對(duì)象，需要多次拼接形成

String時(shí)，應(yīng)該考慮用StringBuffer.append()方法代替。對(duì)大系統(tǒng)而言，應(yīng)該有可調(diào)整的策略來干預(yù)控制垃圾回收。

12. 盡可能地減少嵌套類和內(nèi)部類的使用，杜絕局部類的使用，匿名類只用于監(jiān)聽器(XXXListener)。

13. 不要使用太多的參數(shù)，可以考慮用一個(gè)類來封裝參數(shù)，但參數(shù)類也不能難以構(gòu)造，如果出現(xiàn)這種問題，建議重新考慮設(shè)計(jì)是否合理。

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

15. 文檔， JavaDoc文檔應(yīng)該盡量清楚，對(duì)于提供給開發(fā)人員使用的庫，其對(duì)應(yīng)JavaDoc應(yīng)該詳細(xì)到開發(fā)時(shí)在集成工具中使用而不必再參考其

他文檔的程度，具體包括方法的目的，出參、入?yún)⒌南拗啤⒆兓?#xff0c;以及對(duì)類的狀態(tài)的影響，參見DBC的@pre 和@post條件。

與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的Java在开发中应注意的问题_Java设计编程应该注意的几个问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。