助您寫出優雅的Java代碼七點建議

有的Java程序代碼一眼看上去就讓人以爲混亂且費解，而有的代碼卻能給人如沐春風之感。本文將經過七點建議，幫助您寫出更好、更優雅的程序代碼。

在每一位剛入行的程序員的心中，編寫程序都是一門神聖的藝術創做。他們無不但願本身的代碼做品既簡潔清晰，又可讀性強，並且還具備必定的容錯能力。本文將爲您帶來七點建議和技巧，以幫助您編寫出簡潔、幹練的Java代碼。其中的有些可能會讓你以爲有些難以想象，可是請相信我，以下的每一條我都親身實踐過的。

1.使用IntelliJ IDEA做爲您的集成開發環境(IDE)

雖然我已經使用了六年的Eclipse和三年的NetBeans，並且我仍然偶爾會使用到它們，可是現在的大部分時間，我只使用IntelliJ IDEA(請詳見)。我並非想在這裏展開有關IDE的大討論，而只是想告訴您，IDEA可以根據其自有的最佳整合實踐標準，持續提示您寫出更短、更好、更簡潔的代碼。

您只須要按下Alt + Enter組合鍵，它就會自動開始爲您工做了。在大多數時候，IntelliJ IDEA可以爲您提供各類智能且實用的代碼建議。固然，您也能夠向它學到不一樣的編程知識與技巧。

爲了更好地獲取IDEA的服務性能，您最好在本身的電腦上採用固態硬盤(SSD)。就我本身的那臺舊式筆記本電腦而言，因爲使用的是傳統硬盤(HDD)，它已沒法順暢地運行IDEA了。所以我我的建議您至少使用一顆256 GB大小的固態硬盤。

2.使用JDK 8或更高版本

JDK 8及其更高版本引入了諸如：lambda表達式(lambda expression，一種匿名函數)、功能接口、流式接口(stream APIs，提供更爲可讀的源代碼實現方法)等許多新的功能，這些都有助於您寫出更簡短、更高性能的Java代碼。

固然，您並不須要去逐一地記住這些功能，由於前面提到的IDEA會幫助您在實際編程的過程當中，實現這些功能與服務。這也就是爲何我首先向您建議使用IDEA的緣由。若是您感興趣，也能夠參考《Java8實戰，Java8 in Action》一書，其連接爲：https://amzn.to/2rkOoM0。

3.使用Maven/Gradle

請使用Maven(一個採用純Java編寫的開源項目管理工具，請參見)或Gradle(一個基於Apache Ant和Maven的項目自動化構建工具，請參見)來管理代碼中的依賴關係，以及構建和部署本身的項目。

若是您已經爲許多項目創建了可複用各類基本庫，那麼若是僅僅是內部使用的話，您能夠引入Nexus(一種Maven存儲庫的管理器)來進行管理。不然，您應該將它們直接部署到Maven的中央存儲庫中。

4.使用Lombok

是時候向setter/getter、hashcode/equals、以及constructors/toString等樣板式代碼(boilerplate code)說再見了，您只須要一個註解：- @Data - 就能通通搞定了。

Lombok是一款能夠經過簡單的註解形式，來幫助開發者簡化並消除Java代碼臃腫的工具(具體請參見)。它不但可以減小您的代碼編寫量，還可以幫助您打理那些生成的字節碼。

5.編寫單元測試

可測試的代碼一般意味着在組織結構上具備更合理、更簡潔的代碼質量。由於它會驅使您去事先管理好各個類之間的關係、各類方法的訪問級別、以及其餘方面。我甚至發現：即便是最小的單元測試也可以促進更快、更便捷的開發進程，進而可以讓本身寫出更加短、平、快的Java代碼。

固然在現實開發工做中，您總會聽到一些諸如「我根本沒有時間來編寫單元測試」或「項目時間節點將至，不要浪費時間些單元測試了」之類的反對意見。這些聽起來貌似很合理，可是根據個人經驗，在多數狀況下，事實並不是如此。

若是您沒有時間去編寫單元測試，那您是否有更多的時間，去修復代碼中那些可見、或不可見的bug呢?若是跳過了單元測試，那些倉促完成的代碼將沒法保證穩定性。特別對於一些新的代碼變動而言，您徹底沒法經過及時的反饋途徑，知曉那些新產生的代碼是否存在着錯誤隱患，是否會在未來運行的某個特定場景中產生不可預知的異常問題。

通常而言，Junit和TestNG是兩款很是優秀的Java應用、及單元測試框架。而我我的則更喜歡使用TestNG。

6.重構：常見，但也很慢

簡潔幹練的Java程序代碼歷來不是一蹴而就的，它每每須要您進行反覆地琢磨與改進。經過逐行進行代碼重構、和運行各類測試用例，您能夠確保本身的更改不會破壞既有代碼的正確功能。一樣，IDEA極大地提供了對於代碼重構的支持，其中包括提取方法(extract method，將某個大的函數拆分爲多個小函數)、重命名、內聯(inline)等功能。

固然，若是您對代碼重構是什麼，以及它的做用不太瞭解的話，Martin Fowler的經典著做《重構：改善既有代碼的設計(第2版)，Refactoring: Improving the Design of Existing Code (2nd Edition)》(請詳見)絕對是一本您必備的參考書。

7.按期聯絡客戶，以獲取他們的反饋

最後一點，可能也是最重要的：客戶花錢讓您經過編寫代碼，來解決他們的問題、知足他們的需求、並解決他們的痛點。然而，您可能在不知不覺中花費了太多的時間，去實現自覺得重要、卻對客戶可有可無的特殊功能，進而忽略了代碼總體的健壯性和可維護性。那麼，咱們怎麼纔可以儘早地發現該問題呢?請保持與客戶常常聯繫，以儘早地獲取他們的反饋。

話說回來，知易行難，即便是富有經驗的產品經理也不必定能在較短的時間內領悟需求的真諦，況且是那些滿腦子只注重功能實現的「碼農」們呢?

所以，一個實用的建議是：若是您不能直接聯絡到最終用戶的話，請儘可能與該系統的產品經理、或運維人員進行禮貌、且頻繁的溝通。磨刀不誤砍柴工，這些時間的投入對於後期時間的節省是絕對值得的。

總結

在過去的多年編程實踐和項目應用中，我一直受益於上述七點心得。在此，我但願它們也一樣能給您的代碼工做帶來幫助。祝您編程愉快!