寫代碼不難，難的是寫高質(zhì)量代碼！

作為程序員，要有“刨根問(wèn)底”的精神：知其然，更要知其所以然！

以下為譯文：

在如今這個(gè)時(shí)代，每個(gè)人都在努力提升資源能力。在Web應(yīng)用程序方面，我們有Spring、Play和Struts等框架，這些框架可以幫助我們構(gòu)建具有可擴(kuò)展性和可管理性的軟件。這些框架提供了許多樣板代碼，所以你無(wú)需在應(yīng)用程序中再寫這些代碼。

不過(guò)，寫代碼并不難，但是寫高質(zhì)量的代碼卻很難。

作為開發(fā)人員，在日常工作中我們也應(yīng)該遵循相同的基本原則。我們應(yīng)該將工作完成得盡善盡美，不能將任何錯(cuò)誤留給客戶。很多時(shí)候，迫于壓力開發(fā)人員會(huì)編寫管理不善或復(fù)雜的代碼。為了編寫高質(zhì)量的代碼，有一條經(jīng)驗(yàn)法則是寫出的代碼應(yīng)該讓所有人都能當(dāng)作短語(yǔ)一樣閱讀。

寫代碼時(shí)應(yīng)當(dāng)牢記的事情

多想少寫，在寫之前深思熟慮；

遵循最佳實(shí)踐；

使用SonarQube等代碼質(zhì)量工具，或者如果使用eclipse或IntelliJ等IDE的話，也可以使用Sonar插件（SonarLint），這些都可以輕松入手；

盡量編寫通用的代碼；

不要自行創(chuàng)建API中存在的isEmpty、isNull或isNotNull等方法，許多有名的開源庫(kù)（比如Apache）都提供了定義良好的方法；

使用IDE的重構(gòu)工具，并了解其快捷方式：

publicvoiddoSomething(){Line1....Line2....Line3....Line4....Line5....}

如果你想抽取1-4并創(chuàng)建一個(gè)單獨(dú)的方法。常見的做法是：復(fù)制，創(chuàng)建一個(gè)方法，然后將復(fù)制的行粘貼到該方法中；總共需要3-4步。在做這樣的任務(wù)時(shí)，你可以使用IDE的重構(gòu)工具（而無(wú)需復(fù)制粘貼）。

重構(gòu)工具有許多重要的功能，包括：

將一段代碼從一個(gè)位置移動(dòng)到另一個(gè)位置；

從其他地方抽取一段代碼，然后創(chuàng)建一個(gè)方法（如上例所示）；

重命名文件，變量或方法，注意，如果你手動(dòng)做這個(gè)任務(wù)，那么就需要手動(dòng)修改所有的地方；

盡量編寫正確的測(cè)試用例（可選）。

編寫類

類名應(yīng)該是名詞，每個(gè)單詞的首字母都應(yīng)該大寫；

在編寫新類之前，搜索項(xiàng)目中是否存在這樣的文件。很多時(shí)候，我們會(huì)發(fā)現(xiàn)我們以不同的名稱創(chuàng)建了相同的文件，這會(huì)誤導(dǎo)項(xiàng)目和其他開發(fā)人員。例如：

通過(guò)類名完整地描述的功能；

使用適當(dāng)?shù)脑L問(wèn)修飾符；

文件的打包也非常重要，把正確的文件放在正確的地方，不要把常量文件放在util包等錯(cuò)誤的地方，正確的地方應(yīng)該是常量或元數(shù)據(jù)。

編寫方法

方法是動(dòng)詞，所以名稱應(yīng)該采用駝峰式命名法，例如doWhatToDo()，而非doWHatTODO()；

一個(gè)方法不應(yīng)該超過(guò)30行，如果超過(guò)30行則說(shuō)明過(guò)于復(fù)雜；

在定義方法之前認(rèn)真考慮，方法應(yīng)該具有某些含義，或者應(yīng)該為特定的任務(wù)服務(wù)，例如createPerson或sendMail；

一個(gè)方法不應(yīng)該同時(shí)執(zhí)行多個(gè)任務(wù)，如果方法名為createPerson，那么就應(yīng)該只創(chuàng)建一個(gè)人，不應(yīng)該再做別的任務(wù)。很多人會(huì)這樣做：

publicLongcreatePerson(PersonVOpersonVO){1.Appointmentappointment=tryingtogettinganappointmentfromDB.2.thenperformingifelseovertheresultofappointment.....14.thenupdatingsomethingonthebasisofsomecondition.15.thenfinallycreatingperson.}

很多時(shí)候方法都超過(guò)了這個(gè)限制，開發(fā)人員在一個(gè)方法中編寫100-300行代碼，最后只會(huì)讓代碼面目可憎且難以理解。

引發(fā)的問(wèn)題包括：

無(wú)法理解代碼流；

調(diào)試問(wèn)題；

測(cè)試問(wèn)題；

解決一個(gè)bug需要很長(zhǎng)時(shí)間。

解決方法：

將其他任務(wù)轉(zhuǎn)移到別的方法中；

提取方法中的有效代碼，然后調(diào)用其他方法。

所以，這段代碼應(yīng)該像下面這樣：

publicLongcreatePerson(PersonVOpersonVO){appoitnmentValidation();updatingSomething();creatingpersoncode;}

編寫變量

變量名應(yīng)該采用駝峰式命名法，例如isTrue、userService、personName以及l(fā)ocalServiceRerpository；

不應(yīng)該使用一個(gè)字符的名稱，除非在臨時(shí)情況下；

不應(yīng)該以_和$開頭；

在定義變量名之前認(rèn)真考慮；

不要使用大寫。

編寫常量

盡量通過(guò)類來(lái)定義常量，而不是接口；

定義final類；

在常量類中創(chuàng)建一個(gè)私有構(gòu)造函數(shù)，確保沒人可以創(chuàng)建實(shí)例；

如果你整個(gè)服務(wù)都會(huì)使用唯一的一個(gè)常量文件，那么最好通過(guò)注釋來(lái)分段，如下所示：

/****Cache****/publicstaticfinalStringCACHE_NAME="personCache";/****Attributes****/publicstaticfinalStringNAME="name";publicstaticfinalStringMOBILE="mobile";/****Configuration****/publicstaticfinalStringAPP_NAME="PersonDemo";publicstaticfinalStringAPP_VERSION="1.0";

如此可以方便搜索整個(gè)文件。

常量名應(yīng)該非常具體，應(yīng)該全部使用大寫，并利用下劃線來(lái)分割，例如APP_NAME，而非appName。

編寫邏輯

避免使用多個(gè)嵌套的If else，這會(huì)增加代碼的循環(huán)復(fù)雜度；

盡量編寫通用的代碼；

不要僅僅利用log來(lái)記錄異常，應(yīng)當(dāng)拋出正確的消息或異常，而不是只輸出異常。

什么是“通用代碼”？

在很多項(xiàng)目重構(gòu)的時(shí)候，我們都會(huì)發(fā)現(xiàn)一些本不應(yīng)該存在的冗余代碼。

假設(shè)我們有一個(gè)郵件草稿的POJO類，它的成員會(huì)在發(fā)送郵件時(shí)被使用。那么，發(fā)送郵件所需的步驟有哪些？

我們需要通過(guò)設(shè)置數(shù)據(jù)來(lái)創(chuàng)建一個(gè)POJO對(duì)象；

我們需要編寫發(fā)送郵件的代碼。

那么最終的代碼行數(shù)為：

對(duì)象創(chuàng)建——1行：

MailDraftmailDraft=newMailDraft();

設(shè)置數(shù)據(jù)——3行：

mailDraft.setTo();mailDraft.setBody();mailDraft.setMessage();

發(fā)送郵件的邏輯至少需要4行，所以總共有9-10行代碼。

如果我們需要在多重條件或事件中發(fā)送郵件，那么情況會(huì)怎樣？我們需要相同的邏輯，而且通常我們會(huì)發(fā)現(xiàn)開發(fā)人員在每個(gè)地方都重復(fù)了相同的步驟，并創(chuàng)建一個(gè)擁有某些特定代碼的方法，于是冗余開始層層疊加。

但是，如果我們將創(chuàng)建草稿和發(fā)送郵件的代碼提出來(lái)，放到另一個(gè)方法中，那么每個(gè)方法都可以調(diào)用這段代碼，于是每個(gè)方法都省卻了10行代碼，我們就無(wú)需一次又一次地重復(fù)這段代碼了。

不要匆匆忙忙地趕代碼。如果情非得已，那么也要記得加注釋：

TODO：需要重構(gòu)。