Java開發編程的坑有哪些

這篇文章主要講解了“Java開發編程的坑有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Java開發編程的坑有哪些”吧！

隨處可見的 Null 值

我見過很多的代碼會把 Null 值作為返回值，當你預期是一個字符串時，意外得到了一個 Null 值;當你預期得到一個 List 時，意外又得到了一個  Null 值，如果你不進行處理，那么你還會意外得到 NullPointerException. 就像下面這樣。

// 情況1 String userTag = getUserTag(); if (userTag.equals("admin")) { // NullPointerException    // ... }  // 情況2 List<String> carList = getCarList(); for (String car : carList) { // NullPointerException     // ... }

為了防止這種情況，你可以在 List 返回時給出一個空的集合而不是 Null，如果是字符串，你可以把要確定有值對象放在比較的前面。

if ("admin".equals(userTag)) {     // ... } // 或者 if (Objects.equals(userTag,"admin")){     // ... }

沒有進行空值檢查

可能你考慮到了上面的 Null 值情況，但是在實際處理時沒有考慮空值情況，比如字符空串空串 ""，或者集合為空。那么在后續處理時又有可能得到一個  NullPointerException. 所以你應該進行空值判斷。

String userTag = getUserTag(); if (userTag != null && userTag.trim() != "") {     // ... }  List<String> carList = getCarList(); if (carList != null && !carList.isEmpty()) {     // ... }

忽略的異常處理

異常處理總是一件煩人的事，而忽略異常似乎總有一種吸引人的魔力。我見過像下面這樣的代碼。

try {     List<String> result= request();     // ... }catch (Exception e){  }

你沒有看錯，catch  中沒有任何內容，后來出現了問題，看著日志文件一片太平無跡可尋。異常是故意拋出來的，你應該正確處理它們或者繼續拋出。而且同時，你該輸出一行日志用來記錄這個異常，方便以后的問題追蹤。

沒有釋放資源

在讀取文件或者請求網絡資源時，總是需要進行 close 操作，這很重要，否則可能會阻塞其他線程的使用。但是初學者可能會忘記這一步操作。其實在 Java 7  開始，就提供了 try-with-resources 自動關閉資源的特性，只需要把打開的資源放入 try 中。

try (FileReader fileReader = new FileReader("setting.xml")) {     // fileReader.read();     // ... } catch (Exception e) {     e.printStackTrace(); }

像上面這樣，不需要在 finally 里手動調用 fileReader 的 close 方法關閉資源，因為放在 try 里的資源調用會在使用完畢時自動調用  close. 而且不管是否有異常拋出，這很實用。

ConcuretModificationException

總有一天你會遇到 ConcuretModificationException  ，然后開始百度搜索它的解決方式，這個異常最常見的場景是你在遍歷一個集合時進行更新操作，比如像下面這樣。

List<String> list = new ArrayList<>(); list.add("a1"); list.add("b1"); list.add("b2"); list.add("c1"); for (String s : list) {     if ("b1".equals(s)) {         list.remove(s);     } }

這個異常很有用處，因為 ArrayList  不是線程安全的集合，假設你這邊一邊遍歷，另一個線程不斷更新，非線程安全集合會導致你的遍歷結果不正確，所以這個異常的存在是合理的。同理 HashMap  也是如此

缺少注釋

準確的注釋可以救人于水火，這點有時候一點也不夸張。雖然說優秀的代碼本身就是非常好的注釋，但是這實際開發起來，很少發生。注釋并不需要你事無巨細的一一記錄，但是你該在核心邏輯添加應有的注釋，比如復雜邏輯的實現思路，當前邏輯業務需求。某個判斷的添加原因，某個異常的發生情況等等。這可以讓你在未來的某一天需要回看現在的代碼時感謝自己。更可以讓你在某天的甩鍋中輕松勝出。

不進行代碼測試

我見過有些同事在功能開發完畢后直接扔給對接同事使用，而自己卻沒有經過任何測試，或者只是測試了某個簡單的情況。測試是開發過程中的重要環節，沒有經過嚴格測試的代碼很難說沒有問題，我覺得在功能開發完畢后至少需要單元測試，特殊用例測試，集成測試以及其他形式的測試。嚴格的測試不僅可以第一時間發現問題，更可以減少后面不必要的對接調試時間。

重復造輪子

你知道的，Java 社區非常活躍，存在著大量的第三方類庫，開源作者可能花費了數年時間去維護和完善類庫，這些類庫非常優秀。同時 JDK  也提供了大量的常用的功能封裝。這些都可以為我們的開發速度插上翅膀。所以，當你需要一個功能時候，應該首先看下 JDK  和已經引入的類庫中是否已經存在相同功能，而不是自己重復造輪子，而且大部分情況下你造的輪子還不如別人好。

下面舉些例子。

• 你需要日志記錄，可以使用 logback.

• 你需要網絡操作，可以使用 netty.

• 你需要解析 JSON，可以使用 gson.

• 你需要解析表格，可以使用 apache poi.

• 你需要通用操作，可以使用 apache commons.

另外一種情況是，你可能不知道某個功能在 JDK 中已經實現，這時候你應該多多查看 JDK Document. 我就在工作中見到過同事手寫字符串  split，為了獲取時間戳把 Date 對象轉換到 Calendar.

缺少必要的溝通

這個部分是和開發沒有關系的，但是這個環節往往會影響最終的開發結果。進行具體的開發之前，你應該詳細的溝通并理解功能的需求，這樣你才能針對具體的需求寫出不偏離實際需要的代碼。有時候你很有可能因為缺少必要的溝通，錯誤了理解了需求，最終在開發完畢后發現自己寫的功能完全沒有用處。

沒有代碼規范

代碼規范性非常重要，如果一個項目里充斥著各種稀奇古怪的代碼規范，會讓維護者十分頭疼。而且軟件行業高速發展，對開發者的綜合素質要求也越來越高，優秀的編程習慣也可以提高軟件的最終質量。比如：標新立異的命名風格挑戰閱讀習慣;五花八門的錯誤碼人為地  增加排查問題的難度;工程結構混  亂導致后續項目維護艱難;沒有鑒權的漏洞代碼易被黑客攻擊;質量低下的代碼上線之后漏洞百出等等。因為沒有統一的代碼規范，開發中的問題可能層出不窮。

下面簡單列舉些應該統一的開發規范。如命名風格如何是好;常量名稱結構怎樣;代碼格式怎么統一;日期時間格式如何處理;集合處理注意事項;日志打印有無規范;前后交互具體規約等。

感謝各位的閱讀，以上就是“Java開發編程的坑有哪些”的內容了，經過本文的學習后，相信大家對Java開發編程的坑有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！