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

以下為譯文：

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

不過，寫代碼并不難，但是寫高質量的代碼卻很難。

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

寫代碼時應當牢記的事情

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

遵循最佳實踐；

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

盡量編寫通用的代碼；

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

使用IDE的重構工具，并了解其快捷方式：

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

如果你想抽取1-4并創建一個單獨的方法。常見的做法是：復制，創建一個方法，然后將復制的行粘貼到該方法中；總共需要3-4步。在做這樣的任務時，你可以使用IDE的重構工具（而無需復制粘貼）。

重構工具有許多重要的功能，包括：

將一段代碼從一個位置移動到另一個位置；

從其他地方抽取一段代碼，然后創建一個方法（如上例所示）；

重命名文件，變量或方法，注意，如果你手動做這個任務，那么就需要手動修改所有的地方；

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

編寫類

類名應該是名詞，每個單詞的首字母都應該大寫；

在編寫新類之前，搜索項目中是否存在這樣的文件。很多時候，我們會發現我們以不同的名稱創建了相同的文件，這會誤導項目和其他開發人員。例如：

通過類名完整地描述的功能；

使用適當的訪問修飾符；

文件的打包也非常重要，把正確的文件放在正確的地方，不要把常量文件放在util包等錯誤的地方，正確的地方應該是常量或元數據。

編寫方法

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

一個方法不應該超過30行，如果超過30行則說明過于復雜；

在定義方法之前認真考慮，方法應該具有某些含義，或者應該為特定的任務服務，例如createPerson或sendMail；

一個方法不應該同時執行多個任務，如果方法名為createPerson，那么就應該只創建一個人，不應該再做別的任務。很多人會這樣做：

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

很多時候方法都超過了這個限制，開發人員在一個方法中編寫100-300行代碼，最后只會讓代碼面目可憎且難以理解。

引發的問題包括：

無法理解代碼流；

調試問題；

測試問題；

解決一個bug需要很長時間。

解決方法：

將其他任務轉移到別的方法中；

提取方法中的有效代碼，然后調用其他方法。

所以，這段代碼應該像下面這樣：

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

編寫變量

變量名應該采用駝峰式命名法，例如isTrue、userService、personName以及localServiceRerpository；

不應該使用一個字符的名稱，除非在臨時情況下；

不應該以_和$開頭；

在定義變量名之前認真考慮；

不要使用大寫。

編寫常量

盡量通過類來定義常量，而不是接口；

定義final類；

在常量類中創建一個私有構造函數，確保沒人可以創建實例；

如果你整個服務都會使用唯一的一個常量文件，那么最好通過注釋來分段，如下所示：

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

如此可以方便搜索整個文件。

常量名應該非常具體，應該全部使用大寫，并利用下劃線來分割，例如APP_NAME，而非appName。

編寫邏輯

避免使用多個嵌套的If else，這會增加代碼的循環復雜度；

盡量編寫通用的代碼；

不要僅僅利用log來記錄異常，應當拋出正確的消息或異常，而不是只輸出異常。

什么是“通用代碼”？

在很多項目重構的時候，我們都會發現一些本不應該存在的冗余代碼。

假設我們有一個郵件草稿的POJO類，它的成員會在發送郵件時被使用。那么，發送郵件所需的步驟有哪些？

我們需要通過設置數據來創建一個POJO對象；

我們需要編寫發送郵件的代碼。

那么最終的代碼行數為：

對象創建——1行：

MailDraftmailDraft=newMailDraft();

設置數據——3行：

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

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

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

但是，如果我們將創建草稿和發送郵件的代碼提出來，放到另一個方法中，那么每個方法都可以調用這段代碼，于是每個方法都省卻了10行代碼，我們就無需一次又一次地重復這段代碼了。

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

TODO：需要重構。