【譯】做好這幾件事，程式碼質量可以提升一個檔次
這篇文章又是關於程式碼質量的，有些同學可能覺得我比較囉嗦。不過我就是想用這種方式讓大家重視起來。其實說來說去就那麼幾種方法，但是實際執行起來真是難於登天。
低質量的程式碼真的是一種災難。當你的程式碼變得越來越混亂，維護起來就會花費大量的時間。在最壞的情況下，程式碼將變得不可維護，並且專案會慢慢終止。
為了避免這種情況，你需要注意你的程式碼質量。嘗試在程式碼質量上花費一些時間，長久來看，這將對你有很大的好處。
無論你是管理者，測試人員或者是開發者都應該去自覺維護程式碼質量，因為在整個開發流程中，大家的目標都是交付可用的、高質量的程式碼。
要想提高程式碼質量，需要做到以下六件事，其中一些是一個人可以完成的，而有些則必須要團隊配合。
1. 四眼原則
四眼原則是易於理解和執行的。它的意思是必須要有至少兩個人（包括作者）檢查過程式碼，目前最流行的方法是Pull request。
Pull request是讓你告訴別人你已經在GitHub上向分支push了一些程式碼改動。在開啟Pull request之後，你就可以和協作者討論潛在的問題，並且可以在你的程式碼被merge之前繼續對它進行修改。
——Github.com
在程式碼審查期間，有幾件事需要考慮。其中之一是檢查程式碼是否違反了約定的程式碼規則。這一過程可以通過在管道中使用linter來實現自動化，但有時也需要手動執行。
另外一個需要檢查的是程式碼的可維護性和錯誤處理。這件事還沒辦法自動化。最後，需要檢查的是程式碼的完整性。這一修改是否完成了需要完成的全部功能？
2. 持續整合
“開發環境是好的。”這是某些開發人員常說的，還有就是：“在我電腦上沒問題”。
如果希望避免這種問題的爭論。持續整合可以給你提供很大的幫助。
持續整合是一種軟體開發實踐，團隊的開發人員經常整合他們的工作，通常每人至少每天整合一次——這使得每天需要整合很多次。每次整合都應該由自動構建（包括測試）儘快確認是否存在整合錯誤。
—— Martin Fowler
持續整合的意義在於，它可以快速的向開發者提供結果反饋。
持續整合的兩個基本作用是：
- 保持快速構建，沒什麼比一次耗時一小時的構建更讓人沮喪的了。
- 快速修復損壞的構建。持續整合會讓你始終在一個穩定的版本的基礎上進行開發。
持續整合通過快速向開發者提供反饋來幫助提高程式碼質量。如果測試不通過，那麼構建就會失敗，此時開發者就會注意到。此外，最好在構建指令碼中新增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-c746c30e7