轉(zhuǎn)載自：http://developer.51cto.com/art/201907/598844.htm，如有侵權(quán)請(qǐng)聯(lián)系我刪除箕戳。

今天看了一篇文章，騰訊大佬用他多年的經(jīng)驗(yàn)教我們?nèi)绾螌懗龈哔|(zhì)量的代碼国撵，感觸挺深的陵吸，特此記錄一下。

文章核心

希望看到此篇文章的讀者爭(zhēng)取做一個(gè)優(yōu)秀的程序員介牙。

講述方向

由于一直從事移動(dòng)互聯(lián)網(wǎng)相關(guān)工作壮虫，Java 開發(fā)中經(jīng)常和移動(dòng)端打交道或者做一些后端的工作，所以本篇文章更可能涉及和移動(dòng)端的交互或者與后端的交互方式，筆者希望以自身的一些學(xué)習(xí)經(jīng)驗(yàn)或者開發(fā)經(jīng)驗(yàn)囚似，可以帶動(dòng)認(rèn)真閱讀本篇文章的讀者們剩拢，讓大家對(duì) Java 有一個(gè)更好的態(tài)度去學(xué)習(xí)它，它不只是一個(gè)賺錢的工具而已饶唤。

筆者身邊有很多與筆者年齡相仿或年齡更大的朋友或同事徐伐，經(jīng)常有人問我：“你現(xiàn)在還在學(xué)習(xí)嗎?我覺得沒什么好學(xué)的，這些東西都差不多”募狂，我總是回答只要有時(shí)間办素，我就要看一會(huì)書，這個(gè)時(shí)候祸穷，大家都會(huì)露出一副不屑的眼神或笑容性穿。其實(shí)，非常能理解身邊朋友或同事的看法雷滚，以目前狀態(tài)來講季二，大多都是工作至少 5 年的程序員了，對(duì)于公司大大小小的業(yè)務(wù)需要揭措，以目前的知識(shí)儲(chǔ)備來講胯舷，都可以輕松應(yīng)對(duì)，“沒有什么好學(xué)的”其實(shí)這句話沒有多大的問題绊含，但是桑嘶，如果你對(duì)編程還有一點(diǎn)點(diǎn)興趣，只是不知道如何努力或改進(jìn)躬充，希望本篇文章可以幫到你逃顶。

技術(shù)點(diǎn)

本文不是一個(gè)吹噓的文章，不會(huì)講很多高深的架構(gòu)充甚，相反以政，會(huì)講解很多基礎(chǔ)的問題和寫法問題，如果讀者自認(rèn)為基礎(chǔ)問題和寫法問題都是不是問題伴找，那請(qǐng)忽略這篇文章盈蛮，節(jié)省出時(shí)間去做一些有意義的事情。

開發(fā)工具

不知道有多少”老”程序員還在使用 Eclipse技矮，這些程序員們要不就是因循守舊抖誉，要不就是根本就不知道其他好的開發(fā)工具的存在，Eclipse 吃內(nèi)存卡頓的現(xiàn)象以及各種偶然莫名異常的出現(xiàn)衰倦，都告知我們是時(shí)候?qū)ふ倚碌拈_發(fā)工具了袒炉。

更換 IDE

根本就不想多解釋要換什么樣的 IDE，如果你想成為一個(gè)優(yōu)秀的 Java 程序員樊零，請(qǐng)更換 IntelliJ IDEA我磁。使用 IDEA 的好處，請(qǐng)搜索谷歌。

別告訴我快捷鍵不好用

更換 IDE 不在我本文的重點(diǎn)內(nèi)容中夺艰，所以不想用太多的篇幅去寫為什么更換IDE芋哭。在這里，我只能告訴你劲适，更換 IDE 只為了更好楷掉、更快的寫好 Java 代碼。原因略霞势。

別告訴我快捷鍵不好用烹植，請(qǐng)嘗試新事物。

bean

bean 使我們使用最多的模型之一愕贡，我將以大篇幅去講解 bean草雕，希望讀者好好體會(huì)。

domain 包名

根據(jù)很多 Java 程序員的”經(jīng)驗(yàn)”來看固以，一個(gè)數(shù)據(jù)庫(kù)表則對(duì)應(yīng)著一個(gè) domain 對(duì)象墩虹，所以很多程序員在寫代碼時(shí)，包名則使用：com.xxx.domain 憨琳，這樣寫好像已經(jīng)成為了行業(yè)的一種約束诫钓，數(shù)據(jù)庫(kù)映射對(duì)象就應(yīng)該是 domain。但是你錯(cuò)了篙螟，domain 是一個(gè)領(lǐng)域?qū)ο缶龋覀冊(cè)僮鰝鹘y(tǒng) Java 軟件 Web 開發(fā)中，這些 domain 都是貧血模型遍略，是沒有行為的惧所，或是沒有足夠的領(lǐng)域模型的行為的，所以绪杏，以這個(gè)理論來講下愈，這些 domain 都應(yīng)該是一個(gè)普通的 entity 對(duì)象，并非領(lǐng)域?qū)ο罄倬茫哉?qǐng)把包名改為:com.xxx.entity势似。

如果你還不理解我說的話，請(qǐng)看一下 Vaughn Vernon 出的一本叫做《IMPLEMENTING DOMAIN-DRIVEN DESIGN》(實(shí)現(xiàn)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì))這本書腔彰，書中講解了貧血模型與領(lǐng)域模型的區(qū)別叫编，相信你會(huì)受益匪淺。

DTO

數(shù)據(jù)傳輸我們應(yīng)該使用 DTO 對(duì)象作為傳輸對(duì)象霹抛，這是我們所約定的，因?yàn)楹荛L(zhǎng)時(shí)間我一直都在做移動(dòng)端 API 設(shè)計(jì)的工作卷谈，有很多人告訴我杯拐，他們認(rèn)為只有給手機(jī)端傳輸數(shù)據(jù)的時(shí)候(input or output)，這些對(duì)象成為 DTO 對(duì)象。請(qǐng)注意!這種理解是錯(cuò)誤的端逼，只要是用于網(wǎng)絡(luò)傳輸?shù)膶?duì)象朗兵，我們都認(rèn)為他們可以當(dāng)做是 DTO 對(duì)象，比如電商平臺(tái)中顶滩，用戶進(jìn)行下單余掖，下單后的數(shù)據(jù)，訂單會(huì)發(fā)到 OMS 或者 ERP 系統(tǒng)礁鲁，這些對(duì)接的返回值以及入?yún)⒁步?DTO 對(duì)象盐欺。

我們約定某對(duì)象如果是 DTO 對(duì)象，就將名稱改為 XXDTO仅醇，比如訂單下發(fā)OMS：OMSOrderInputDTO冗美。

DTO 轉(zhuǎn)化

正如我們所知，DTO 為系統(tǒng)與外界交互的模型對(duì)象析二，那么肯定會(huì)有一個(gè)步驟是將 DTO 對(duì)象轉(zhuǎn)化為 BO 對(duì)象或者是普通的 entity 對(duì)象粉洼，讓 service 層去處理。

場(chǎng)景

比如添加會(huì)員操作叶摄，由于用于演示属韧，我只考慮用戶的一些簡(jiǎn)單數(shù)據(jù)，當(dāng)后臺(tái)管理員點(diǎn)擊添加用戶時(shí)蛤吓，只需要傳過來用戶的姓名和年齡就可以了宵喂，后端接受到數(shù)據(jù)后，將添加創(chuàng)建時(shí)間和更新時(shí)間和默認(rèn)密碼三個(gè)字段柱衔，然后保存數(shù)據(jù)庫(kù)樊破。

@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); 
 } 
} 

我們只關(guān)注一下上述代碼中的轉(zhuǎn)化代碼，其他內(nèi)容請(qǐng)忽略：

User user = new User(); 
user.setUsername(userInputDTO.getUsername()); 
user.setAge(userInputDTO.getAge());

請(qǐng)使用工具

上邊的代碼唆铐，從邏輯上講哲戚，是沒有問題的，只是這種寫法讓我很厭煩艾岂，例子中只有兩個(gè)字段顺少，如果有 20 個(gè)字段，我們要如何做呢? 一個(gè)一個(gè)進(jìn)行 set 數(shù)據(jù)嗎?當(dāng)然王浴，如果你這么做了脆炎，肯定不會(huì)有什么問題，但是氓辣，這肯定不是一個(gè)最優(yōu)的做法秒裕。

網(wǎng)上有很多工具，支持淺拷貝或深拷貝的 Utils钞啸。舉個(gè)例子几蜻，我們可以使用 org.springframework.beans.BeanUtils#copyProperties 對(duì)代碼進(jìn)行重構(gòu)和優(yōu)化：

@PostMapping 
public User addUser(UserInputDTO userInputDTO){ 
 User user = new User(); 
 BeanUtils.copyProperties(userInputDTO,user); 
 return userService.addUser(user); 
}

BeanUtils.copyProperties 是一個(gè)淺拷貝方法喇潘，復(fù)制屬性時(shí)，我們只需要把 DTO 對(duì)象和要轉(zhuǎn)化的對(duì)象兩個(gè)的屬性值設(shè)置為一樣的名稱梭稚，并且保證一樣的類型就可以了颖低。如果你在做 DTO 轉(zhuǎn)化的時(shí)候一直使用 set 進(jìn)行屬性賦值，那么請(qǐng)嘗試這種方式簡(jiǎn)化代碼弧烤，讓代碼更加清晰!

轉(zhuǎn)化的語義

上邊的轉(zhuǎn)化過程忱屑，讀者看后肯定覺得優(yōu)雅很多，但是我們?cè)賹?Java 代碼時(shí)暇昂，更多的需要考慮語義的操作莺戒，再看上邊的代碼：

User user = new User(); 
BeanUtils.copyProperties(userInputDTO,user); 

雖然這段代碼很好的簡(jiǎn)化和優(yōu)化了代碼，但是他的語義是有問題的话浇，我們需要提現(xiàn)一個(gè)轉(zhuǎn)化過程才好脏毯，所以代碼改成如下：

@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; 
 } 

這是一個(gè)更好的語義寫法，雖然他麻煩了些幔崖，但是可讀性大大增加了食店，在寫代碼時(shí)，我們應(yīng)該盡量把語義層次差不多的放到一個(gè)方法中赏寇，比如：

User user = convertFor(userInputDTO); 
return userService.addUser(user); 

這兩段代碼都沒有暴露實(shí)現(xiàn)吉嫩，都是在講如何在同一個(gè)方法中，做一組相同層次的語義操作嗅定，而不是暴露具體的實(shí)現(xiàn)自娩。

如上所述，是一種重構(gòu)方式渠退，讀者可以參考 Martin Fowler 的《Refactoring Imporving the Design of Existing Code》(重構(gòu) 改善既有代碼的設(shè)計(jì)) 這本書中的 Extract Method 重構(gòu)方式忙迁。

抽象接口定義

當(dāng)實(shí)際工作中，完成了幾個(gè) API 的 DTO 轉(zhuǎn)化時(shí)碎乃，我們會(huì)發(fā)現(xiàn)姊扔，這樣的操作有很多很多，那么應(yīng)該定義好一個(gè)接口梅誓，讓所有這樣的操作都有規(guī)則的進(jìn)行恰梢。

如果接口被定義以后，那么 convertFor 這個(gè)方法的語義將產(chǎn)生變化梗掰，它將是一個(gè)實(shí)現(xiàn)類嵌言。

看一下抽象后的接口：

public interface DTOConvert<S,T> { 
 T convert(S s); 
} 

雖然這個(gè)接口很簡(jiǎn)單，但是這里告訴我們一個(gè)事情及穗，要去使用泛型摧茴，如果你是一個(gè)優(yōu)秀的 Java 程序員，請(qǐng)為你想做的抽象接口埂陆，做好泛型吧蓬蝶。

我們?cè)賮砜唇涌趯?shí)現(xiàn)：

public class UserInputDTOConvert implements DTOConvert { 
@Override 
public User convert(UserInputDTO userInputDTO) { 
User user = new User(); 
BeanUtils.copyProperties(userInputDTO,user); 
return user; 
} 
} 

我們這樣重構(gòu)后尘分，我們發(fā)現(xiàn)現(xiàn)在的代碼是如此的簡(jiǎn)潔猜惋，并且那么的規(guī)范：

@RequestMapping("/v1/api/user") 
@RestController 
public class UserApi { 
 @Autowired 
 private UserService userService; 
 @PostMapping 
 public User addUser(UserInputDTO userInputDTO){ 
 User user = new UserInputDTOConvert().convert(userInputDTO); 
 return userService.addUser(user); 
 } 
} 

review code

如果你是一個(gè)優(yōu)秀的 Java 程序員丸氛，我相信你應(yīng)該和我一樣，已經(jīng)數(shù)次重復(fù) review 過自己的代碼很多次了著摔。

我們?cè)倏催@個(gè)保存用戶的例子缓窜，你將發(fā)現(xiàn)，API 中返回值是有些問題的谍咆，問題就在于不應(yīng)該直接返回 User 實(shí)體禾锤，因?yàn)槿绻@樣的話，就暴露了太多實(shí)體相關(guān)的信息摹察，這樣的返回值是不安全的恩掷，所以我們更應(yīng)該返回一個(gè) DTO 對(duì)象，我們可稱它為 UserOutputDTO：

@PostMapping 
public UserOutputDTO addUser(UserInputDTO userInputDTO){ 
 User user = new UserInputDTOConvert().convert(userInputDTO); 
 User saveUserResult = userService.addUser(user); 
 UserOutputDTO result = new UserOutDTOConvert().convertToUser(saveUserResult); 
 return result; 
} 

這樣你的 API 才更健全供嚎。

不知道在看完這段代碼之后黄娘，讀者有是否發(fā)現(xiàn)還有其他問題的存在，作為一個(gè)優(yōu)秀的 Java 程序員克滴，請(qǐng)看一下這段我們剛剛抽象完的代碼:

User user = new UserInputDTOConvert().convert(userInputDTO); 

你會(huì)發(fā)現(xiàn)逼争，new 這樣一個(gè) DTO 轉(zhuǎn)化對(duì)象是沒有必要的，而且每一個(gè)轉(zhuǎn)化對(duì)象都是由在遇到 DTO 轉(zhuǎn)化的時(shí)候才會(huì)出現(xiàn)劝赔，那我們應(yīng)該考慮一下誓焦，是否可以將這個(gè)類和 DTO 進(jìn)行聚合呢，看一下我的聚合結(jié)果:

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; 
 } 
 } 
} 

然后 API 中的轉(zhuǎn)化則由：

User user = new UserInputDTOConvert().convert(userInputDTO); 
User saveUserResult = userService.addUser(user); 

變成了：

User user = userInputDTO.convertToUser(); 
User saveUserResult = userService.addUser(user); 

我們?cè)?DTO 對(duì)象中添加了轉(zhuǎn)化的行為着帽，我相信這樣的操作可以讓代碼的可讀性變得更強(qiáng)杂伟，并且是符合語義的。

再查工具類

再來看 DTO 內(nèi)部轉(zhuǎn)化的代碼仍翰，它實(shí)現(xiàn)了我們自己定義的 DTOConvert 接口赫粥，但是這樣真的就沒有問題，不需要再思考了嗎?

我覺得并不是歉备，對(duì)于 Convert 這種轉(zhuǎn)化語義來講傅是，很多工具類中都有這樣的定義，這中 Convert 并不是業(yè)務(wù)級(jí)別上的接口定義蕾羊，它只是用于普通 bean 之間轉(zhuǎn)化屬性值的普通意義上的接口定義喧笔，所以我們應(yīng)該更多的去讀其他含有 Convert 轉(zhuǎn)化語義的代碼。

我仔細(xì)閱讀了一下 GUAVA 的源碼龟再，發(fā)現(xiàn)了 com.google.common.base.Convert 這樣的定義：

public abstract class Converter<A, B> implements Function<A, B> { 
 protected abstract B doForward(A a); 
 protected abstract A doBackward(B b); 
 //其他略 
} 

從源碼可以了解到书闸，GUAVA 中的 Convert 可以完成正向轉(zhuǎn)化和逆向轉(zhuǎn)化，繼續(xù)修改我們 DTO 中轉(zhuǎn)化的這段代碼：

private static class UserInputDTOConvert implements DTOConvert<UserInputDTO,User> { 
 @Override 
 public User convert(UserInputDTO userInputDTO) { 
 User user = new User(); 
 BeanUtils.copyProperties(userInputDTO,user); 
 return user; 
 } 
} 

修改后：

private static class UserInputDTOConvert extends Converter<UserInputDTO, User> { 
 @Override 
 protected User doForward(UserInputDTO userInputDTO) { 
 User user = new User(); 
 BeanUtils.copyProperties(userInputDTO,user); 
 return user; 
 } 
 @Override 
 protected UserInputDTO doBackward(User user) { 
 UserInputDTO userInputDTO = new UserInputDTO(); 
 BeanUtils.copyProperties(user,userInputDTO); 
 return userInputDTO; 
 } 
 } 

看了這部分代碼以后利凑，你可能會(huì)問浆劲，那逆向轉(zhuǎn)化會(huì)有什么用呢?其實(shí)我們有很多小的業(yè)務(wù)需求中嫌术，入?yún)⒑统鰠⑹且粯拥模敲次覀冏兛梢暂p松的進(jìn)行轉(zhuǎn)化牌借，我將上邊所提到的 UserInputDTO 和 UserOutputDTO 都轉(zhuǎn)成 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：

@PostMapping 
 public UserDTO addUser(UserDTO userDTO){ 
 User user = userDTO.convertToUser(); 
 User saveResultUser = userService.addUser(user); 
 UserDTO result = userDTO.convertFor(saveResultUser); 
 return result; 
 } 

當(dāng)然，上述只是表明了轉(zhuǎn)化方向的正向或逆向膨报，很多業(yè)務(wù)需求的出參和入?yún)⒌?DTO 對(duì)象是不同的磷籍，那么你需要更明顯的告訴程序：逆向是無法調(diào)用的：

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("不支持逆向轉(zhuǎn)化方法!"); 
 } 
 } 

看一下 doBackward 方法，直接拋出了一個(gè)斷言異常现柠，而不是業(yè)務(wù)異常苗膝，這段代碼告訴代碼的調(diào)用者采记，這個(gè)方法不是準(zhǔn)你調(diào)用的郭卫，如果你調(diào)用囤攀，我就”斷言”你調(diào)用錯(cuò)誤了。

關(guān)于異常處理的更詳細(xì)介紹周循，可以參考我之前的文章：如何優(yōu)雅的設(shè)計(jì) Java 異常(http://lrwinx.github.io/2016/04/28/%E5%A6%82%E4%BD%95%E4%BC%98%E9%9B%85%E7%9A%84%E8%AE%BE%E8%AE%A1java%E5%BC%82%E5%B8%B8/) 强法，應(yīng)該可以幫你更好的理解異常。

bean 的驗(yàn)證

如果你認(rèn)為我上邊寫的那個(gè)添加用戶 API 寫的已經(jīng)非常完美了鱼鼓，那只能說明你還不是一個(gè)優(yōu)秀的程序員拟烫。我們應(yīng)該保證任何數(shù)據(jù)的入?yún)⒌椒椒w內(nèi)都是合法的。

為什么要驗(yàn)證

很多人會(huì)告訴我迄本，如果這些 API 是提供給前端進(jìn)行調(diào)用的硕淑，前端都會(huì)進(jìn)行驗(yàn)證啊，你為什還要驗(yàn)證?

其實(shí)答案是這樣的嘉赎，我從不相信任何調(diào)用我 API 或者方法的人置媳，比如前端驗(yàn)證失敗了，或者某些人通過一些特殊的渠道(比如 Charles 進(jìn)行抓包)公条，直接將數(shù)據(jù)傳入到我的 API拇囊，那我仍然進(jìn)行正常的業(yè)務(wù)邏輯處理，那么就有可能產(chǎn)生臟數(shù)據(jù)!

“對(duì)于臟數(shù)據(jù)的產(chǎn)生一定是致命”靶橱，這句話希望大家牢記在心寥袭，再小的臟數(shù)據(jù)也有可能讓你找?guī)讉€(gè)通宵!

jsr 303驗(yàn)證

hibernate 提供的 jsr 303 實(shí)現(xiàn)，我覺得目前仍然是很優(yōu)秀的关霸，具體如何使用传黄，我不想講，因?yàn)楣雀枭夏憧梢运阉鞒龊芏啻鸢?

再以上班的 API 實(shí)例進(jìn)行說明队寇，我們現(xiàn)在對(duì) DTO 數(shù)據(jù)進(jìn)行檢查：

public class UserDTO { 
 @NotNull 
 private String username; 
 @NotNull 
 private int age; 
 //其他代碼略 
} 

API 驗(yàn)證：

@PostMapping 
 public UserDTO addUser(@Valid UserDTO userDTO){ 
 User user = userDTO.convertToUser(); 
 User saveResultUser = userService.addUser(user); 
 UserDTO result = userDTO.convertFor(saveResultUser); 
 return result; 
 } 

我們需要將驗(yàn)證結(jié)果傳給前端膘掰，這種異常應(yīng)該轉(zhuǎn)化為一個(gè) api 異常(帶有錯(cuò)誤碼的異常)。

@PostMapping 
public UserDTO addUser(@Valid UserDTO userDTO, BindingResult bindingResult){ 
 checkDTOParams(bindingResult); 
 User user = userDTO.convertToUser(); 
 User saveResultUser = userService.addUser(user); 
 UserDTO result = userDTO.convertFor(saveResultUser); 
 return result; 
} 
private void checkDTOParams(BindingResult bindingResult){ 
 if(bindingResult.hasErrors()){ 
 //throw new 帶驗(yàn)證碼的驗(yàn)證錯(cuò)誤異常 
 } 
} 

BindingResult 是 Spring MVC 驗(yàn)證 DTO 后的一個(gè)結(jié)果集佳遣，可以參考spring 官方文檔(http://spring.io/)识埋。

檢查參數(shù)后凡伊，可以拋出一個(gè)“帶驗(yàn)證碼的驗(yàn)證錯(cuò)誤異常”窒舟，具體異常設(shè)計(jì)可以參考如何優(yōu)雅的設(shè)計(jì) Java 異常(http://lrwinx.github.io/2016/04/28/%E5%A6%82%E4%BD%95%E4%BC%98%E9%9B%85%E7%9A%84%E8%AE%BE%E8%AE%A1java%E5%BC%82%E5%B8%B8/)系忙。

擁抱 lombok

上邊的 DTO 代碼，已經(jīng)讓我看的很累了辜纲，我相信讀者也是一樣笨觅，看到那么多的 Getter 和 Setter 方法，太煩躁了耕腾，那時(shí)候有什么方法可以簡(jiǎn)化這些呢。

請(qǐng)擁抱 lombok,它會(huì)幫助我們解決一些讓我們很煩躁的問題

去掉 Setter 和 Getter

其實(shí)這個(gè)標(biāo)題杀糯，我不太想說扫俺，因?yàn)榫W(wǎng)上太多，但是因?yàn)楹芏嗳烁嬖V我固翰，他們根本就不知道 lombok 的存在狼纬，所以為了讓讀者更好的學(xué)習(xí)，我愿意寫這樣一個(gè)例子：

@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("不支持逆向轉(zhuǎn)化方法!"); 
 } 
 } 
} 

看到了吧骂际，煩人的 Getter 和 Setter 方法已經(jīng)去掉了疗琉。

但是上邊的例子根本不足以體現(xiàn) lombok 的強(qiáng)大。我希望寫一些網(wǎng)上很難查到歉铝，或者很少人進(jìn)行說明的 lombok 的使用以及在使用時(shí)程序語義上的說明盈简。

比如:@Data,@AllArgsConstructor,@NoArgsConstructor..這些我就不進(jìn)行一一說明了，請(qǐng)大家自行查詢資料太示。

bean 中的鏈?zhǔn)斤L(fēng)格

什么是鏈?zhǔn)斤L(fēng)格?我來舉個(gè)例子柠贤，看下面這個(gè) 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; 
 } 
} 

仔細(xì)看一下 set 方法，這樣的設(shè)置便是 chain 的 style类缤，調(diào)用的時(shí)候臼勉，可以這樣使用：

Student student = new Student() 
 .setAge(24) 
 .setName("zs"); 

相信合理使用這樣的鏈?zhǔn)酱a，會(huì)更多的程序帶來很好的可讀性餐弱，那看一下如果使用 lombok 進(jìn)行改善呢宴霸，請(qǐng)使用 @Accessors(chain = true)，看如下代碼：

@Accessors(chain = true) 
@Setter 
@Getter 
public class Student { 
 private String name; 
 private int age; 
} 

這樣就完成了一個(gè)對(duì)于 bean 來講很友好的鏈?zhǔn)讲僮鳌?/p>

靜態(tài)構(gòu)造方法

靜態(tài)構(gòu)造方法的語義和簡(jiǎn)化程度真的高于直接去 new 一個(gè)對(duì)象膏蚓。比如 new 一個(gè) List 對(duì)象瓢谢，過去的使用是這樣的：

List<String> list = new ArrayList<>(); 

看一下 guava 中的創(chuàng)建方式：

List<String> list = Lists.newArrayList(); 

Lists 命名是一種約定(俗話說：約定優(yōu)于配置)，它是指 Lists 是 List 這個(gè)類的一個(gè)工具類降允，那么使用 List 的工具類去產(chǎn)生 List恩闻，這樣的語義是不是要比直接 new 一個(gè)子類來的更直接一些呢，答案是肯定的剧董，再比如如果有一個(gè)工具類叫做 Maps幢尚，那你是否想到了創(chuàng)建 Map 的方法呢：

HashMap<String, String> objectObjectHashMap = Maps.newHashMap(); 

好了破停，如果你理解了我說的語義，那么尉剩，你已經(jīng)向成為 Java 程序員更近了一步了真慢。

再回過頭來看剛剛的 Student，很多時(shí)候理茎，我們?nèi)?Student 這個(gè) bean 的時(shí)候黑界，他會(huì)有一些必輸字段，比如 Student 中的 name 字段皂林，一般處理的方式是將 name 字段包裝成一個(gè)構(gòu)造方法朗鸠，只有傳入 name 這樣的構(gòu)造方法，才能創(chuàng)建一個(gè) Student 對(duì)象础倍。

接上上邊的靜態(tài)構(gòu)造方法和必傳參數(shù)的構(gòu)造方法烛占，使用 lombok 將更改成如下寫法(@RequiredArgsConstructor 和 @NonNull):

@Accessors(chain = true) 
@Setter 
@Getter 
@RequiredArgsConstructor(staticName = "ofName") 
public class Student { 
 @NonNull private String name; 
 private int age; 
} 

測(cè)試代碼：

Student student = Student.ofName("zs"); 

這樣構(gòu)建出的 bean 語義是否要比直接 new 一個(gè)含參的構(gòu)造方法(包含 name 的構(gòu)造方法)要好很多。

當(dāng)然沟启，看過很多源碼以后忆家，我想相信將靜態(tài)構(gòu)造方法 ofName 換成 of 會(huì)先的更加簡(jiǎn)潔：

@Accessors(chain = true) 
@Setter 
@Getter 
@RequiredArgsConstructor(staticName = "of") 
public class Student { 
 @NonNull private String name; 
 private int age; 
} 

測(cè)試代碼：

Student student = Student.of("zs"); 

當(dāng)然他仍然是支持鏈?zhǔn)秸{(diào)用的：

Student student = Student.of("zs").setAge(24); 

這樣來寫代碼，真的很簡(jiǎn)潔德迹，并且可讀性很強(qiáng)芽卿。

使用 builder

Builder 模式我不想再多解釋了，讀者可以看一下《Head First》(設(shè)計(jì)模式) 的建造者模式胳搞。

今天其實(shí)要說的是一種變種的 builder 模式卸例，那就是構(gòu)建 bean 的 builder 模式，其實(shí)主要的思想是帶著大家一起看一下 lombok 給我們帶來了什么流酬。

看一下 Student 這個(gè)類的原始 builder 狀態(tài):

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; 
 } 
 } 
} 

調(diào)用方式：

Student student = Student.builder().name("zs").age(24).build(); 

這樣的 builder 代碼币厕，讓我是在惡心難受，于是我打算用 lombok 重構(gòu)這段代碼：

@Builder 
public class Student { 
 private String name; 
 private int age; 
} 

調(diào)用方式：

Student student = Student.builder().name("zs").age(24).build(); 

代理模式

正如我們所知的芽腾，在程序中調(diào)用 rest 接口是一個(gè)常見的行為動(dòng)作旦装，如果你和我一樣使用過 spring 的 RestTemplate，我相信你會(huì)我和一樣摊滔，對(duì)他拋出的非 http 狀態(tài)碼異常深惡痛絕阴绢。

所以我們考慮將 RestTemplate 最為底層包裝器進(jìn)行包裝器模式的設(shè)計(jì)：

public abstract class FilterRestTemplate implements RestOperations { 
 protected volatile RestTemplate restTemplate; 
 protected FilterRestTemplate(RestTemplate restTemplate){ 
 this.restTemplate = restTemplate; 
 } 
 //實(shí)現(xiàn)RestOperations所有的接口 
} 

然后再由擴(kuò)展類對(duì) FilterRestTemplate 進(jìn)行包裝擴(kuò)展：

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 很完美的更改了異常拋出的行為，讓程序更具有容錯(cuò)性艰躺。在這里我們不考慮 ExtractRestTemplate 完成的功能呻袭，讓我們把焦點(diǎn)放在 FilterRestTemplate 上，“實(shí)現(xiàn) RestOperations 所有的接口”,這個(gè)操作絕對(duì)不是一時(shí)半會(huì)可以寫完的腺兴，當(dāng)時(shí)在重構(gòu)之前我?guī)缀鯇懥税雮€(gè)小時(shí),如下：

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); 
 } 
 //其他實(shí)現(xiàn)代碼略左电。。。 
} 

我相信你看了以上代碼篓足，你會(huì)和我一樣覺得惡心反胃段誊，后來我用 lombok 提供的代理注解優(yōu)化了我的代碼(@Delegate)：

@AllArgsConstructor 
public abstract class FilterRestTemplate implements RestOperations { 
 @Delegate 
 protected volatile RestTemplate restTemplate; 
} 

這幾行代碼完全替代上述那些冗長(zhǎng)的代碼。

是不是很簡(jiǎn)潔栈拖，做一個(gè)擁抱 lombok 的程序員吧连舍。

重構(gòu)

需求案例

項(xiàng)目需求

項(xiàng)目開發(fā)階段，有一個(gè)關(guān)于下單發(fā)貨的需求：如果今天下午 3 點(diǎn)前進(jìn)行下單涩哟，那么發(fā)貨時(shí)間是明天索赏，如果今天下午 3 點(diǎn)后進(jìn)行下單，那么發(fā)貨時(shí)間是后天贴彼，如果被確定的時(shí)間是周日潜腻，那么在此時(shí)間上再加 1 天為發(fā)貨時(shí)間。

思考與重構(gòu)

我相信這個(gè)需求看似很簡(jiǎn)單锻弓，無論怎么寫都可以完成砾赔。

很多人可能看到這個(gè)需求，就動(dòng)手開始寫 Calendar 或 Date 進(jìn)行計(jì)算青灼，從而完成需求。

而我給的建議是妓盲，仔細(xì)考慮如何寫代碼杂拨，然后再去寫，不是說所有的時(shí)間操作都用 Calendar 或 Date 去解決悯衬，一定要看場(chǎng)景弹沽。

對(duì)于時(shí)間的計(jì)算我們要考慮 joda-time 這種類似的成熟時(shí)間計(jì)算框架來寫代碼，它會(huì)讓代碼更加簡(jiǎn)潔和易讀筋粗。

請(qǐng)讀者先考慮這個(gè)需求如何用 Java 代碼完成策橘，或先寫一個(gè)你覺得完成這個(gè)代碼的思路，再來看我下邊的代碼娜亿，這樣丽已，你的收獲會(huì)更多一些：

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() ; 
} 

讀這段代碼的時(shí)候，你會(huì)發(fā)現(xiàn)买决，我將判斷和有可能出現(xiàn)的不同結(jié)果都當(dāng)做一個(gè)變量沛婴，最終做一個(gè)三目運(yùn)算符的方式進(jìn)行返回，這樣的優(yōu)雅和可讀性顯而易見督赤，當(dāng)然這樣的代碼不是一蹴而就的嘁灯，我優(yōu)化了 3 遍產(chǎn)生的以上代碼。讀者可根據(jù)自己的代碼和我寫的代碼進(jìn)行對(duì)比躲舌。

提高方法

如果你做了 3 年+的程序員丑婿，我相信像如上這樣的需求，你很輕松就能完成，但是如果你想做一個(gè)會(huì)寫 Java 的程序員羹奉，就好好的思考和重構(gòu)代碼吧秒旋。

寫代碼就如同寫字一樣，同樣的字尘奏，大家都會(huì)寫滩褥，但是寫出來是否好看就不一定了。如果想把程序?qū)懞渺偶樱鸵粩嗟乃伎己椭貥?gòu)瑰煎，敢于嘗試，敢于創(chuàng)新俗孝，不要因循守舊酒甸，一定要做一個(gè)優(yōu)秀的 Java 程序員。

提高代碼水平最好的方法就是有條理的重構(gòu)!(注意：是有條理的重構(gòu))

設(shè)計(jì)模式

設(shè)計(jì)模式就是工具赋铝，而不是提現(xiàn)你是否是高水平程序員的一個(gè)指標(biāo)插勤。

我經(jīng)常會(huì)看到某一個(gè)程序員興奮的大喊，哪個(gè)程序哪個(gè)點(diǎn)我用到了設(shè)計(jì)模式革骨，寫的多么多么優(yōu)秀农尖，多么多么好。我仔細(xì)去翻閱的時(shí)候良哲，卻發(fā)現(xiàn)有很多是過度設(shè)計(jì)的盛卡。

業(yè)務(wù)驅(qū)動(dòng)技術(shù) or 技術(shù)驅(qū)動(dòng)業(yè)務(wù)

業(yè)務(wù)驅(qū)動(dòng)技術(shù) or 技術(shù)驅(qū)動(dòng)業(yè)務(wù) ? 其實(shí)這是一個(gè)一直在爭(zhēng)論的話題，但是很多人不這么認(rèn)為筑凫，我覺得就是大家不愿意承認(rèn)罷了滑沧。我來和大家大概分析一下作為一個(gè) Java 程序員，我們應(yīng)該如何判斷自己所處于的位置.

業(yè)務(wù)驅(qū)動(dòng)技術(shù)：如果你所在的項(xiàng)目是一個(gè)收益很小或者甚至沒有收益的項(xiàng)目巍实，請(qǐng)不要搞其他創(chuàng)新的東西滓技，不要驅(qū)動(dòng)業(yè)務(wù)要如何如何做，而是要熟知業(yè)務(wù)現(xiàn)在的痛點(diǎn)是什么?如何才能幫助業(yè)務(wù)盈利或者讓項(xiàng)目更好棚潦，更順利的進(jìn)行令漂。

技術(shù)驅(qū)動(dòng)業(yè)務(wù)：如果你所在的項(xiàng)目是一個(gè)很牛的項(xiàng)目，比如淘寶這類的項(xiàng)目瓦盛，我可以在滿足業(yè)務(wù)需求的情況下洗显，和業(yè)務(wù)溝通，使用什么樣的技術(shù)能更好的幫助業(yè)務(wù)創(chuàng)造收益原环，比如說下單的時(shí)候要進(jìn)隊(duì)列挠唆，可能幾分鐘之后訂單狀態(tài)才能處理完成，但是會(huì)讓用戶有更流暢的體驗(yàn)嘱吗，賺取更多的訪問流量玄组，那么我相信業(yè)務(wù)愿意被技術(shù)驅(qū)動(dòng)滔驾，會(huì)同意訂單的延遲問題，這樣便是技術(shù)驅(qū)動(dòng)業(yè)務(wù)俄讹。

我相信大部分人還都處于業(yè)務(wù)驅(qū)動(dòng)技術(shù)的方向吧哆致。

所以你既然不能驅(qū)動(dòng)業(yè)務(wù)，那就請(qǐng)擁抱業(yè)務(wù)變化吧患膛。

代碼設(shè)計(jì)

一直在做 Java 后端的項(xiàng)目摊阀，經(jīng)常會(huì)有一些變動(dòng)，我相信大家也都遇到過踪蹬。

比如當(dāng)我們寫一段代碼的時(shí)候胞此，我們考慮將需求映射成代碼的狀態(tài)模式，突然有一天跃捣，狀態(tài)模式里邊又添加了很多行為變化的東西漱牵，這時(shí)候你就撓頭了，你硬生生的將狀態(tài)模式中添加過多行為和變化疚漆。

慢慢的你會(huì)發(fā)現(xiàn)這些狀態(tài)模式酣胀，其實(shí)更像是一簇算法，應(yīng)該使用策略模式娶聘，這時(shí)你應(yīng)該已經(jīng)暈頭轉(zhuǎn)向了闻镶。

說了這么多，我的意思是丸升，只要你覺得合理儒溉，就請(qǐng)將狀態(tài)模式改為策略模式吧，所有的模式并不是憑空想象出來的发钝，都是基于重構(gòu)。

Java 編程中沒有銀彈波闹，請(qǐng)擁抱業(yè)務(wù)變化酝豪，一直思考重構(gòu)，你就有一個(gè)更好的代碼設(shè)計(jì)!

你真的優(yōu)秀嗎?

真不好意思精堕，我取了一個(gè)這么無聊的標(biāo)題孵淘。

國(guó)外流行一種編程方式，叫做結(jié)對(duì)編程歹篓，我相信國(guó)內(nèi)很多公司都沒有這么做瘫证，我就不在講述結(jié)對(duì)編程帶來的好處了，其實(shí)就是一邊 code review庄撮，一邊互相提高的一個(gè)過程背捌。既然做不到這個(gè)，那如何讓自己活在自己的世界中不斷提高呢?

“平時(shí)開發(fā)的時(shí)候洞斯，做出的代碼總認(rèn)為是正確的毡庆，而且寫法是完美的。”么抗，我相信這是大部分人的心聲毅否，還回到剛剛的問題，如何在自己的世界中不斷提高呢?

答案就是:

　　1. 多看成熟框架的源碼
　　2. 多回頭看自己的代碼
　　3. 勤于重構(gòu)

你真的優(yōu)秀嗎? 如果你每周都完成了學(xué)習(xí)源碼蝇刀，回頭看自己代碼螟加，然后勤于重構(gòu)，我認(rèn)為你就真的很優(yōu)秀了吞琐。

即使也許你只是剛剛?cè)腴T捆探，但是一直堅(jiān)持，你就是一個(gè)真的會(huì)寫java代碼的程序員了顽分。

技能

UML

不想多討論 UML 相關(guān)的知識(shí)徐许，但是我覺得你如果真的會(huì)寫 Java，請(qǐng)先學(xué)會(huì)表達(dá)自己卒蘸，UML 就是你說話的語言雌隅，做一名優(yōu)秀的 Java 程序員，請(qǐng)至少學(xué)會(huì)這兩種 UML 圖：

　　1. 類圖
　　2. 時(shí)序圖

clean code

我認(rèn)為保持代碼的簡(jiǎn)潔和可讀性是代碼的最基本保證缸沃，如果有一天為了程序的效率而降低了這兩點(diǎn)恰起，我認(rèn)為是可以諒解的，除此之外趾牧，沒有任何理由可以讓你任意揮霍你的代碼检盼。

讀者可以看一下 Robert C. Martin 出版的《Clean Code》(代碼整潔之道) 這本書

　　1. 可以參考美團(tuán)文章聊聊 clean code(http://tech.meituan.com/clean-code.html);
　　2. 也可以看一下阿里的 Java 編碼規(guī)范(https://yq.aliyun.com/articles/69327?spm=5176.100239.topwz.1.om5dRN)。
　　3. 無論如何翘单，請(qǐng)保持你的代碼的整潔吨枉。
Linux 基礎(chǔ)命令

這點(diǎn)其實(shí)和會(huì)寫 Java 沒有關(guān)系，但是 Linux 很多時(shí)候確實(shí)承載運(yùn)行 Java 的容器哄芜，請(qǐng)學(xué)好 Linux 的基礎(chǔ)命令貌亭。