【譯】作好這幾件事，代碼質量能夠提高一個檔次

這篇文章又是關於代碼質量的，有些同窗可能以爲我比較囉嗦。不過我就是想用這種方式讓你們重視起來。其實說來講去就那麼幾種方法，可是實際執行起來真是難於登天。

低質量的代碼真的是一種災難。當你的代碼變得愈來愈混亂，維護起來就會花費大量的時間。在最壞的狀況下，代碼將變得不可維護，而且項目會慢慢終止。

爲了不這種狀況，你須要注意你的代碼質量。嘗試在代碼質量上花費一些時間，長久來看，這將對你有很大的好處。

不管你是管理者，測試人員或者是開發者都應該去自覺維護代碼質量，由於在整個開發流程中，你們的目標都是交付可用的、高質量的代碼。

要想提升代碼質量，須要作到如下六件事，其中一些是一我的能夠完成的，而有些則必需要團隊配合。

1. 四眼原則

四眼原則是易於理解和執行的。它的意思是必需要有至少兩我的（包括做者）檢查過代碼，目前最流行的方法是Pull request。

Pull request是讓你告訴別人你已經在GitHub上向分支push了一些代碼改動。在開啓Pull request以後，你就能夠和協做者討論潛在的問題，而且能夠在你的代碼被merge以前繼續對它進行修改。

——Github.com

在代碼審查期間，有幾件事須要考慮。其中之一是檢查代碼是否違反了約定的代碼規則。這一過程能夠經過在管道中使用linter來實現自動化，但有時也須要手動執行。

另一個須要檢查的是代碼的可維護性和錯誤處理。這件事還沒辦法自動化。最後，須要檢查的是代碼的完整性。這一修改是否完成了須要完成的所有功能？

2. 持續集成

「開發環境是好的。」這是某些開發人員常說的，還有就是：「在我電腦上沒問題」。

若是但願避免這種問題的爭論。持續集成能夠給你提供很大的幫助。

持續集成是一種軟件開發實踐，團隊的開發人員常常集成他們的工做，一般每人至少天天集成一次——這使得天天須要集成不少次。每次集成都應該由自動構建（包括測試）儘快確認是否存在集成錯誤。

—— Martin Fowler

持續集成的意義在於，它能夠快速的向開發者提供結果反饋。

持續集成的兩個基本做用是：

1. 保持快速構建，沒什麼比一次耗時一小時的構建更讓人沮喪的了。
2. 快速修復損壞的構建。持續集成會讓你始終在一個穩定的版本的基礎上進行開發。

持續集成經過快速向開發者提供反饋來幫助提升代碼質量。若是測試不經過，那麼構建就會失敗，此時開發者就會注意到。此外，最好在構建腳本中添加linter來檢查是否符合編碼規範。毫無疑問，這也是用於提升代碼質量的。

3. 編碼規範

擁有一系列的代碼規約是很是重要的。可是在你開始制定代碼規約以前，團隊的每一個人都應該參與。由於這期間可能存在大量的關於最優約定的討論。

編碼規範中應該包括怎樣聲明和命名一個變量等等。規則的數量是沒有限制的，而且之後能夠繼續調整，前提是這些規則對你和你的團隊有幫助。

當編碼規範制定好之後，請務必遵照。就像我前面提到的，最好的檢查辦法是在管道中增長linter，這樣就不須要人工干預了。若是不這樣作，也能夠選擇在本地安裝linter。但要保證在每次提交以前規範使用linter。這樣你的團隊的代碼風格將很是統一，有利於提高代碼的可讀性和可維護性。

高質量的代碼能夠加快軟件開發的速度，由於它能夠被複用，而且開發人員沒必要花費大量時間修改bug和完善代碼。同時新人加入項目也會更快適應。

4. 測試，測試，測試

代碼質量越高，bug就越少。咱們一般經過測試過濾出嚴重的bug，確保代碼按照預期執行。

制定清晰的測試策略對於提升代碼質量相當重要。至少要保證你的代碼能夠經過單元測試。若是你以其餘方式進行測試就更好了，例如集成測試或迴歸測試。

根據測試金字塔，項目中數量最多的測試應該是單元測試，由於它們既簡單又快速。有不少工具能夠幫助你建立單元測試並生成代碼覆蓋率報告。

跑單元測試和生成代碼覆蓋率報告能夠經過持續集成自動進行。當代碼覆蓋率達不到要求時，持續集成也會構建失敗。

5. 分析bug

代碼中有bug是必然的事情，如何處理這些bug纔是關鍵。若是你想要提高本身，學會從錯誤中學習相當重要。這也是爲何你要分析bug。

發現bug後，先分析bug的影響。是一個低優先級的仍是高優先級的？若是是高優先級的，就須要儘快解決。

分析bug時，你須要問本身一些問題。是什麼致使了錯誤？爲何沒有測出來？其餘地方也有可能發生嗎？以及咱們應該怎樣避免相似的bug產生？

固然，咱們也要學會使用工具追蹤bug。目前市面上有許多可用的bug追蹤工具，你能夠根據須要選擇適合本身的工具。

6. 開始量化

在開始量化時，能夠用幾個指標來衡量代碼的質量。

缺陷指標

缺陷的數量和缺陷的嚴重程度是衡量代碼質量的重要指標。若是你想追蹤bug，可使用bug燃盡圖。bug燃盡圖和軟件敏捷開發中的正常燃盡圖同樣。惟一不一樣的是bug燃盡圖包含未修復的bug，而不是事故點。

複雜度指標

複雜度一般由圈複雜度衡量，它是程序的源代碼線性獨立路徑數量的一個衡量。

圈複雜度數和缺陷頻率之間存在必定的相關性：

許多研究調查了函數或方法中圈複雜度數和缺陷頻率數之間的相關性。有些研究發現了圈複雜度和缺陷數的正相關性：函數和方法越複雜，缺陷也就會越多。然而，圈複雜度和程序大小之間的相關性已被屢次證實。

從理論上來說，下降代碼的複雜度會使缺陷更少。

原文地址

https://medium.com/better-programming/things-that-you-can-do-to-improve-code-quality-c746c30e7521