其實，本不想把标題寫的那麼恐怖，隻是發現很多人幹了幾年 Java 以後，都自認為是一個不錯的 Java 程式員了，可以拿着上萬的工資都處宣揚自己了，寫這篇文章的目的并不是嘲諷和我一樣做 Java 的同行們，隻是希望讀者看到此篇文章後，可以和我一樣，心平氣和的争取做一個優秀的程式員。
@RequestMapping("/v1/api/user")
@RestController
public class UserApi {
@Autowired
private UserService userService;
@PostMapping
public User addUser(UserInputDTO userInputDTO){
User user = new User();
user.setUsername(userInputDTO.getUsername());
user.setAge(userInputDTO.getAge());
return userService.addUser(user);
}
} 我們隻關注一下上述代碼中的轉化代碼，其他内容請忽略：
User user = new User();
user.setUsername(userInputDTO.getUsername());
user.setAge(userInputDTO.getAge()); 請使用工具
上邊的代碼，從邏輯上講，是沒有問題的，隻是這種寫法讓我很厭煩，例子中隻有兩個字段，如果有 20 個字段，我們要如何做呢？ 一個一個進行 set 資料嗎？當然，如果你這麼做了，肯定不會有什麼問題，但是，這肯定不是一個最優的做法。推薦：排名前 16 的 Java 工具類！
網上有很多工具，支援淺拷貝或深拷貝的 Utils。舉個例子，我們可以使用 org.springframework.beans.BeanUtils#copyProperties 對代碼進行重構和優化：
@PostMapping
public User addUser(UserInputDTO userInputDTO){
User user = new User();
BeanUtils.copyProperties(userInputDTO,user);
return userService.addUser(user);
} BeanUtils.copyProperties 是一個淺拷貝方法，複制屬性時，我們隻需要把 DTO 對象和要轉化的對象兩個的屬性值設定為一樣的名稱，并且保證一樣的類型就可以了。如果你在做 DTO 轉化的時候一直使用 set 進行屬性指派，那麼請嘗試這種方式簡化代碼，讓代碼更加清晰!
轉化的語義
上邊的轉化過程，讀者看後肯定覺得優雅很多，但是我們再寫 Java 代碼時，更多的需要考慮語義的操作，再看上邊的代碼：
User user = new User();
BeanUtils.copyProperties(userInputDTO,user);
1
雖然這段代碼很好的簡化和優化了代碼，但是他的語義是有問題的，我們需要提現一個轉化過程才好，是以代碼改成如下
@PostMapping
public User addUser(UserInputDTO userInputDTO){
User user = convertFor(userInputDTO);
return userService.addUser(user);
}
private User convertFor(UserInputDTO userInputDTO){
User user = new User();
BeanUtils.copyProperties(userInputDTO,user);
return user;
} 這兩段代碼都沒有暴露實作，都是在講如何在同一個方法中，做一組相同層次的語義操作，而不是暴露具體的實作。
如上所述，是一種重構方式，讀者可以參考 Martin Fowler 的《Refactoring Imporving the Design of Existing Code》(重構 改善既有代碼的設計) 這本書中的 Extract Method 重構方式。
抽象接口定義
當實際工作中，完成了幾個 API 的 DTO 轉化時，我們會發現，這樣的操作有很多很多，那麼應該定義好一個接口，讓所有這樣的操作都有規則的進行。
如果接口被定義以後，那麼 convertFor 這個方法的語義将産生變化，它将是一個實作類。
看一下抽象後的接口：
review code
如果你是一個優秀的 Java 程式員，我相信你應該和我一樣，已經數次重複 review 過自己的代碼很多次了。
我們再看這個儲存使用者的例子，你将發現，API 中傳回值是有些問題的，問題就在于不應該直接傳回 User 實體，因為如果這樣的話，就暴露了太多實體相關的資訊，這樣的傳回值是不安全的，是以我們更應該傳回一個 DTO 對象，我們可稱它為 UserOutputDTO：
public class UserInputDTO {
private String username;
private int age;
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
public User convertToUser(){
UserInputDTOConvert userInputDTOConvert = new UserInputDTOConvert();
User convert = userInputDTOConvert.convert(this);
return convert;
}
private static class UserInputDTOConvert implements DTOConvert<UserInputDTO,User> {
@Override
public User convert(UserInputDTO userInputDTO) {
User user = new User();
BeanUtils.copyProperties(userInputDTO,user);
return user;
}
}
} 我們再 DTO 對象中添加了轉化的行為，我相信這樣的操作可以讓代碼的可讀性變得更強，并且是符合語義的。
再查工具類
再來看 DTO 内部轉化的代碼，它實作了我們自己定義的 DTOConvert 接口，但是這樣真的就沒有問題，不需要再思考了嗎？
我覺得并不是，對于 Convert 這種轉化語義來講，很多工具類中都有這樣的定義，這中 Convert 并不是業務級别上的接口定義，它隻是用于普通 bean 之間轉化屬性值的普通意義上的接口定義，是以我們應該更多的去讀其他含有 Convert 轉化語義的代碼。推薦：排名前 16 的 Java 工具類！
我仔細閱讀了一下 GUAVA 的源碼，發現了 com.google.common.base.Convert 這樣的定義：
看了這部分代碼以後，你可能會問，那逆向轉化會有什麼用呢？其實我們有很多小的業務需求中，入參和出參是一樣的，那麼我們變可以輕松的進行轉化，我将上邊所提到的 UserInputDTO 和 UserOutputDTO 都轉成 UserDTO 展示給大家。
DTO：
public class UserDTO {
private String username;
private int age;
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
public User convertToUser(){
UserDTOConvert userDTOConvert = new UserDTOConvert();
User convert = userDTOConvert.convert(this);
return convert;
}
public UserDTO convertFor(User user){
UserDTOConvert userDTOConvert = new UserDTOConvert();
UserDTO convert = userDTOConvert.reverse().convert(user);
return convert;
}
private static class UserDTOConvert extends Converter<UserDTO, User> {
@Override
protected User doForward(UserDTO userDTO) {
User user = new User();
BeanUtils.copyProperties(userDTO,user);
return user;
}
@Override
protected UserDTO doBackward(User user) {
UserDTO userDTO = new UserDTO();
BeanUtils.copyProperties(user,userDTO);
return userDTO;
}
}
} API：
看一下 doBackward 方法，直接抛出了一個斷言異常，而不是業務異常，這段代碼告訴代碼的調用者，這個方法不是準你調用的，如果你調用，我就”斷言”你調用錯誤了。
bean 的驗證
如果你認為我上邊寫的那個添加使用者 API 寫的已經非常完美了，那隻能說明你還不是一個優秀的程式員。我們應該保證任何資料的入參到方法體内都是合法的。推薦：Spring Boot 如何做參數校驗？
為什麼要驗證
很多人會告訴我，如果這些 API 是提供給前端進行調用的，前端都會進行驗證啊，你為什還要驗證？
其實答案是這樣的，我從不相信任何調用我 API 或者方法的人，比如前端驗證失敗了，或者某些人通過一些特殊的管道(比如 Charles 進行抓包)，直接将資料傳入到我的 API，那我仍然進行正常的業務邏輯處理，那麼就有可能産生髒資料！
“對于髒資料的産生一定是緻命”，這句話希望大家牢記在心，再小的髒資料也有可能讓你找幾個通宵！
jsr 303驗證
hibernate 提供的 jsr 303 實作，我覺得目前仍然是很優秀的，具體如何使用，我不想講，因為谷歌上你可以搜尋出很多答案!
再以上班的 API 執行個體進行說明，我們現在對 DTO 資料進行檢查：
BindingResult 是 Spring MVC 驗證 DTO 後的一個結果集，可以參考spring 官方文檔（
http://spring.io/）。
擁抱 lombok
上邊的 DTO 代碼，已經讓我看的很累了，我相信讀者也是一樣，看到那麼多的 Getter 和 Setter 方法，太煩躁了，那時候有什麼方法可以簡化這些呢。推薦一款代碼神器，代碼量至少省一半！
請擁抱 lombok,它會幫助我們解決一些讓我們很煩躁的問題
去掉 Setter 和 Getter
其實這個标題，我不太想說，因為網上太多，但是因為很多人告訴我，他們根本就不知道 lombok 的存在，是以為了讓讀者更好的學習，我願意寫這樣一個例子：
@Setter
@Getter
public class UserDTO {
@NotNull
private String username;
@NotNull
private int age;
public User convertToUser(){
UserDTOConvert userDTOConvert = new UserDTOConvert();
User convert = userDTOConvert.convert(this);
return convert;
}
public UserDTO convertFor(User user){
UserDTOConvert userDTOConvert = new UserDTOConvert();
UserDTO convert = userDTOConvert.reverse().convert(user);
return convert;
}
private static class UserDTOConvert extends Converter<UserDTO, User> {
@Override
protected User doForward(UserDTO userDTO) {
User user = new User();
BeanUtils.copyProperties(userDTO,user);
return user;
}
@Override
protected UserDTO doBackward(User user) {
throw new AssertionError("不支援逆向轉化方法!");
}
}
} 看到了吧，煩人的 Getter 和 Setter 方法已經去掉了。
但是上邊的例子根本不足以展現 lombok 的強大。我希望寫一些網上很難查到，或者很少人進行說明的 lombok 的使用以及在使用時程式語義上的說明。
比如:@Data,@AllArgsConstructor,@NoArgsConstructor..這些我就不進行一一說明了，請大家自行查詢資料。
bean 中的鍊式風格
什麼是鍊式風格？我來舉個例子，看下面這個 Student 的 bean：
public class Student {
private String name;
private int age;
public String getName() {
return name;
}
public Student setName(String name) {
this.name = name;
return this;
}
public int getAge() {
return age;
}
public Student setAge(int age) {
return this;
}
} Lists 命名是一種約定(俗話說：約定優于配置)，它是指 Lists 是 List 這個類的一個工具類，那麼使用 List 的工具類去産生 List，這樣的語義是不是要比直接 new 一個子類來的更直接一些呢，答案是肯定的，再比如如果有一個工具類叫做 Maps，那你是否想到了建立 Map 的方法呢：
HashMap objectObjectHashMap = Maps.newHashMap();
好了，如果你了解了我說的語義，那麼，你已經向成為 Java 程式員更近了一步了。
再回過頭來看剛剛的 Student，很多時候，我們去寫 Student 這個 bean 的時候，他會有一些必輸字段，比如 Student 中的 name 字段，一般處理的方式是将 name 字段包裝成一個構造方法，隻有傳入 name 這樣的構造方法，才能建立一個 Student 對象。
接上上邊的靜态構造方法和必傳參數的構造方法，使用 lombok 将更改成如下寫法（@RequiredArgsConstructor 和 @NonNull）:
@Accessors(chain = true)
@Setter
@Getter
@RequiredArgsConstructor(staticName = "ofName")
public class Student {
@NonNull private String name;
private int age;
} 這樣來寫代碼，真的很簡潔，并且可讀性很強。
使用 builder
Builder 模式我不想再多解釋了，讀者可以看一下《Head First》(設計模式) 的建造者模式。
今天其實要說的是一種變種的 builder 模式，那就是建構 bean 的 builder 模式，其實主要的思想是帶着大家一起看一下 lombok 給我們帶來了什麼。
看一下 Student 這個類的原始 builder 狀态:
public class Student {
private String name;
private int age;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
public static Builder builder(){
return new Builder();
}
public static class Builder{
private String name;
private int age;
public Builder name(String name){
this.name = name;
return this;
}
public Builder age(int age){
this.age = age;
return this;
}
public Student build(){
Student student = new Student();
student.setAge(age);
student.setName(name);
return student;
}
}
} public class ExtractRestTemplate extends FilterRestTemplate {
private RestTemplate restTemplate;
public ExtractRestTemplate(RestTemplate restTemplate) {
super(restTemplate);
this.restTemplate = restTemplate;
}
public <T> RestResponseDTO<T> postForEntityWithNoException(String url, Object request, Class<T> responseType, Object... uriVariables)
throws RestClientException {
RestResponseDTO<T> restResponseDTO = new RestResponseDTO<T>();
ResponseEntity<T> tResponseEntity;
try {
tResponseEntity = restTemplate.postForEntity(url, request, responseType, uriVariables);
restResponseDTO.setData(tResponseEntity.getBody());
restResponseDTO.setMessage(tResponseEntity.getStatusCode().name());
restResponseDTO.setStatusCode(tResponseEntity.getStatusCodeValue());
}catch (Exception e){
restResponseDTO.setStatusCode(RestResponseDTO.UNKNOWN_ERROR);
restResponseDTO.setMessage(e.getMessage());
restResponseDTO.setData(null);
}
return restResponseDTO;
}
} 包裝器 ExtractRestTemplate 很完美的更改了異常抛出的行為，讓程式更具有容錯性。在這裡我們不考慮 ExtractRestTemplate 完成的功能，讓我們把焦點放在 FilterRestTemplate 上，“實作 RestOperations 所有的接口”,這個操作絕對不是一時半會可以寫完的，當時在重構之前我幾乎寫了半個小時,如下：
public abstract class FilterRestTemplate implements RestOperations {
protected volatile RestTemplate restTemplate;
protected FilterRestTemplate(RestTemplate restTemplate) {
this.restTemplate = restTemplate;
}
@Override
public <T> T getForObject(String url, Class<T> responseType, Object... uriVariables) throws RestClientException {
return restTemplate.getForObject(url,responseType,uriVariables);
}
@Override
public <T> T getForObject(String url, Class<T> responseType, Map<String, ?> uriVariables) throws RestClientException {
return restTemplate.getForObject(url,responseType,uriVariables);
}
@Override
public <T> T getForObject(URI url, Class<T> responseType) throws RestClientException {
return restTemplate.getForObject(url,responseType);
}
@Override
public <T> ResponseEntity<T> getForEntity(String url, Class<T> responseType, Object... uriVariables) throws RestClientException {
return restTemplate.getForEntity(url,responseType,uriVariables);
}
//其他實作代碼略。。。
} 我相信你看了以上代碼，你會和我一樣覺得惡心反胃，後來我用 lombok 提供的代理注解優化了我的代碼(@Delegate)：
@AllArgsConstructor
public abstract class FilterRestTemplate implements RestOperations {
@Delegate
protected volatile RestTemplate restTemplate;
} 這幾行代碼完全替代上述那些冗長的代碼。
是不是很簡潔，做一個擁抱 lombok 的程式員吧。
重構
需求案例
項目需求
項目開發階段，有一個關于下單發貨的需求：如果今天下午 3 點前進行下單，那麼發貨時間是明天，如果今天下午 3 點後進行下單，那麼發貨時間是後天，如果被确定的時間是周日，那麼在此時間上再加 1 天為發貨時間。
思考與重構
我相信這個需求看似很簡單，無論怎麼寫都可以完成。
很多人可能看到這個需求，就動手開始寫 Calendar 或 Date 進行計算，進而完成需求。
而我給的建議是，仔細考慮如何寫代碼，然後再去寫，不是說所有的時間操作都用 Calendar 或 Date 去解決，一定要看場景。
對于時間的計算我們要考慮 joda-time 這種類似的成熟時間計算架構來寫代碼，它會讓代碼更加簡潔和易讀。
請讀者先考慮這個需求如何用 Java 代碼完成，或先寫一個你覺得完成這個代碼的思路，再來看我下邊的代碼，這樣，你的收獲會更多一些：
final DateTime DISTRIBUTION\_TIME\_SPLIT_TIME = new DateTime().withTime(15,0,0,0);
private Date calculateDistributionTimeByOrderCreateTime(Date orderCreateTime){
DateTime orderCreateDateTime = new DateTime(orderCreateTime);
Date tomorrow = orderCreateDateTime.plusDays(1).toDate();
Date theDayAfterTomorrow = orderCreateDateTime.plusDays(2).toDate();
return orderCreateDateTime.isAfter(DISTRIBUTION\_TIME\_SPLIT_TIME) ? wrapDistributionTime(theDayAfterTomorrow) : wrapDistributionTime(tomorrow);
}
private Date wrapDistributionTime(Date distributionTime){
DateTime currentDistributionDateTime = new DateTime(distributionTime);
DateTime plusOneDay = currentDistributionDateTime.plusDays(1);
boolean isSunday = (DateTimeConstants.SUNDAY == currentDistributionDateTime.getDayOfWeek());
return isSunday ? plusOneDay.toDate() : currentDistributionDateTime.toDate() ;
} 讀這段代碼的時候，你會發現，我将判斷和有可能出現的不同結果都當做一個變量，最終做一個三目運算符的方式進行傳回，這樣的優雅和可讀性顯而易見，當然這樣的代碼不是一蹴而就的，我優化了 3 遍産生的以上代碼。讀者可根據自己的代碼和我寫的代碼進行對比。
提高方法
如果你做了 3 年+的程式員，我相信像如上這樣的需求，你很輕松就能完成，但是如果你想做一個會寫 Java 的程式員，就好好的思考和重構代碼吧。
寫代碼就如同寫字一樣，同樣的字，大家都會寫，但是寫出來是否好看就不一定了。如果想把程式寫好，就要不斷的思考和重構，敢于嘗試，敢于創新，不要因循守舊，一定要做一個優秀的 Java 程式員。
提高代碼水準最好的方法就是有條理的重構！(注意：是有條理的重構)
設計模式
設計模式就是工具，而不是提現你是否是高水準程式員的一個名額。
我經常會看到某一個程式員興奮的大喊，哪個程式哪個點我用到了設計模式，寫的多麼多麼優秀，多麼多麼好。我仔細去翻閱的時候，卻發現有很多是過度設計的。
業務驅動技術 or 技術驅動業務
業務驅動技術 or 技術驅動業務 ？ 其實這是一個一直在争論的話題，但是很多人不這麼認為，我覺得就是大家不願意承認罷了。我來和大家大概分析一下作為一個 Java 程式員，我們應該如何判斷自己所處于的位置.
業務驅動技術：如果你所在的項目是一個收益很小或者甚至沒有收益的項目，請不要搞其他創新的東西，不要驅動業務要如何如何做，而是要熟知業務現在的痛點是什麼？如何才能幫助業務盈利或者讓項目更好，更順利的進行。
技術驅動業務：如果你所在的項目是一個很牛的項目，比如淘寶這類的項目，我可以在滿足業務需求的情況下，和業務溝通，使用什麼樣的技術能更好的幫助業務創造收益，比如說下單的時候要進隊列，可能幾分鐘之後訂單狀态才能處理完成，但是會讓使用者有更流暢的體驗，賺取更多的通路流量，那麼我相信業務願意被技術驅動，會同意訂單的延遲問題，這樣便是技術驅動業務。
我相信大部分人還都處于業務驅動技術的方向吧。
是以你既然不能驅動業務，那就請擁抱業務變化吧。
代碼設計
一直在做 Java 後端的項目，經常會有一些變動，我相信大家也都遇到過。
比如當我們寫一段代碼的時候，我們考慮将需求映射成代碼的狀态模式，突然有一天，狀态模式裡邊又添加了很多行為變化的東西，這時候你就撓頭了，你硬生生的将狀态模式中添加過多行為和變化。
慢慢的你會發現這些狀态模式，其實更像是一簇算法，應該使用政策模式，這時你應該已經暈頭轉向了。
說了這麼多，我的意思是，隻要你覺得合理，就請将狀态模式改為政策模式吧，所有的模式并不是憑空想象出來的，都是基于重構。
Java 程式設計中沒有銀彈，請擁抱業務變化，一直思考重構，你就有一個更好的代碼設計!
你真的優秀嗎？
真不好意思，我取了一個這麼無聊的标題。
國外流行一種程式設計方式，叫做結對程式設計，我相信國内很多公司都沒有這麼做，我就不在講述結對程式設計帶來的好處了，其實就是一邊 code review，一邊互相提高的一個過程。既然做不到這個，那如何讓自己活在自己的世界中不斷提高呢？
“平時開發的時候，做出的代碼總認為是正确的，而且寫法是完美的。”，我相信這是大部分人的心聲，還回到剛剛的問題，如何在自己的世界中不斷提高呢？
答案就是:
多看成熟架構的源碼
多回頭看自己的代碼
勤于重構
你真的優秀嗎？ 如果你每周都完成了學習源碼，回頭看自己代碼，然後勤于重構，我認為你就真的很優秀了。
即使也許你隻是剛剛入門，但是一直堅持，你就是一個真的會寫java代碼的程式員了。
技能
UML
不想多讨論 UML 相關的知識，但是我覺得你如果真的會寫 Java，請先學會表達自己，UML 就是你說話的語言，做一名優秀的 Java 程式員，請至少學會這兩種 UML 圖：
類圖
時序圖
clean code
我認為保持代碼的簡潔和可讀性是代碼的最基本保證，如果有一天為了程式的效率而降低了這兩點，我認為是可以諒解的，除此之外，沒有任何理由可以讓你任意揮霍你的代碼。
無論如何，請保持你的代碼的整潔。
Linux 基礎指令
這點其實和會寫 Java 沒有關系，但是 Linux 很多時候确實承載運作 Java 的容器，請學好 Linux 的基礎指令。
參考鳥哥的《Linux私房菜》
總結
Java 是一個大體系，今天讨論并未涉及架構和架構相關知識，隻是讨論如何寫好代碼。
本文從寫 Java 程式的小方面一直寫到大方面，來闡述了如何才能寫好 Java 程式，并告訴讀者們如何才能提高自身的編碼水準。
我希望看到這篇文章的各位都能做一個優秀的 Java 程式員。