寫高質量的代碼，永不言晚！

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

作者 | Nitesh sharma

譯者 | 彎月

責編 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下為譯文：

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

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

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

寫代碼時應當牢記的事情

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

遵循最佳實踐；

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

盡量編寫通用的代碼；

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

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

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

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

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

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

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

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

編寫類

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

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

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

使用適當的訪問修飾符；

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

編寫方法

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

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

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

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

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

引發的問題包括：

無法理解代碼流；

調試問題；

測試問題；

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

解決方法：

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

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

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

編寫變數

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

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

不應該以_和$開頭；

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

不要使用大寫。

編寫常量

盡量通過類來定義常量，而不是介面；

定義final類；

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

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

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

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

編寫邏輯

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

盡量編寫通用的代碼；

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

什麼是「通用代碼」？

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

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

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

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

那麼最終的代碼行數為：

對象創建——1行：

設置數據——3行：

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

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

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

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

原文：https://dzone.com/articles/its-not-too-late

作者：Nitesh sharma， 高級軟體工程師@GlobalLogic。

本文為 CSDN 翻譯，如需轉載，請註明來源出處。

熱 文推 薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！