當你讀完本文，就可以按照我介紹的七個技巧與竅門編寫出簡潔、整齊的 Java 代碼。它們中的一些可能性會讓你感到驚訝。
但是請相信我，它們通過了實踐的驗證——至少在我這裡。
我持續使用 Eclipse IDE已經近6年，另外 NetBeans 3年。我有時仍然使用它們，但是大多數的時間我只用 IntelliJ IDE。
我不想在這裡展示 IDE 或者編輯器的聖戰，但我想告訴你，IDEA 會提醒你基於其集成的最佳實踐，以便讓我們編寫更簡短、更好、更清晰的代碼。我們只需要按下 ALT + Enter，它將為你完成工作。在大多數時間裡，InterlliJ IDEA 為你提供智能和實用的建議；你還可以從中獲得各種各樣新的信息。
為了更好的使用 IDE，最好使用 SSD硬盤，至少我這麼做了——我的另一臺舊筆記本電腦就無法流暢的運行 IDE。其實很簡單，只需要一個 256G 的 Samsung SSD 就可以讓你的生活很美好。如果你還在使用 HDD，這筆投資是絕對值得的。
2. 使用 JDK 8 或更高版本從 JDK 8 以及 更高版本開始，引進許多新功能可以讓你編寫更簡短、更具表現力的代碼，包括 lambda 表達式、functional 接口、Stream API等。你實際上並不需要記住它們，IDE 會幫助你使用這些函數，這也是你應該使用 IDE 的另一個好處。另外，《Java 8 in Action》 一書對你也會有所幫助。
3. 使用 Maven/Gradle為我們的項目使用 Maven 或 Gradle 來管理依賴、構建與部署。若你已經構建了許多基礎庫並在許多項目中重用，如果這些庫僅在內部使用，這最好引入 Nexus。否則，你應該將它們部署到 Maven 中央存儲庫。
4. 使用 Lombok與 setter/getter、hashcode/equals 以及 constructors/toString 這樣的模板代碼說再見。你只需要一個註解——@Data——就可以開始工作。Lombok 能減少你編寫的代碼，但是它依然會處理生成的字節碼。
5. 編寫單元測試What？你是認真的嗎？！
沒錯。經過單元測試後的代碼通常組織的更好、更清晰，因為它促使你要把類的關係管理好、方法的訪問級別以及其它細節內容。我發現即便是最小的單元測試也會使開發更快更容易，它總能驅動你編寫更簡短、更清晰、更優質的代碼。
但是，你總會聽到反面的言論，比如“我們有時間編寫單元測試”或者“在上線日期來臨時這是在浪費時間”。這聽起來是真的，有時候這也確實是事實。但是大部分時間，從我的經驗來看，它肯定不是上面所說的那樣。
如果你沒有時間來編寫單元測試，你會花費更多時間來修復可見或不可見的 bug，如果沒有單元測試的快速反饋，代碼的穩定性通常會降低，新的改動一般會減少，有時，你可能需要認真地祈禱，因為真的不知道將發生什麼或將引入多少個新的 bug。
可能一些天才程序員可以寫出不需要單元測試而沒有 bug 的代碼。但是我不是，你可能也不是。所以去做吧——請相信我。
JUnit 和 TestNG 做單元測試工作都能做得很好，它們的一些重要功能：
1. 易於設置和運行。
2. 支持註釋。
3. 允許忽略或分組並一起執行某些測試。
4. 支持參數化測試，即通過在運行時指定不同的值來運行單元測試。
5. 通過與構建工具，如Ant，Maven和Gradle集成來支持自動化的測試執行。
不過我更喜歡 TestNG。
6. 重構：勤而緩
更短、更簡潔的代碼不能一次完成，它需要我們反覆改進。一點一點的重構並運行測試用例以確保你的更改不會破壞代碼的正確行為，事情也會變得越來越好。
在此處，IDE 提供了很好的重構支持，比如提取方法、重命名、內聯等特性。
如果你不知道什麼是重構並想要了解更多，Martin Flower 的一本書 《重構:改善既有代碼的設計》 值得你一讀。
7. 定期拜訪客戶並獲得他們的反饋老實說，這一項應該放在列表的第一位。但在這種情況下，“最好的都在最後”。你編寫的代碼是為了解決用戶的問題，滿足需求並消除用戶的痛點。有時，你卻浪費了太多時間實現不必要的特性和功能。
但是如何能讓你早點知道呢？定期與客戶保持聯繫，以便儘早得到他們的反饋。但是這並不像你想象的那麼容易，即便是經驗豐富的產品經理也無法在短時間內獲得信息，甚至比主要關注功能實現的程序員還要少。
給你一個實際的建議，如果無法直接與客戶聯繫，你應該經常與你的產品負責人溝通，清楚且有禮貌的談談你的問題，這會節省很多時間。
在過去的多年編程實踐和項目應用中，我一直受益於上面七個心得。我希望它們也同樣能給您的代碼工作帶來幫助。
愉快地編碼！
閱讀更多 KOne社區 的文章
