當您的軟件團隊快速增長時，確保代碼質量是一個巨大的挑戰。但是，即使有固定數量的軟件開發人員，維護代碼質量也會引起麻煩。
如果沒有工具和一致的系統，整個項目可能積累巨大的技術債務，長期造成的問題比短期解決的問題要多。
最好的事情是，你不必成為一個火箭科學家來避免這一點（當然，如果你是火箭科學家的話，這不是問題）。
我們提供了一個很重的指南，幫助您從根本上提高團隊生成的代碼的質量，無論您是與內部團隊還是軟件外包公司合作。
這篇文章的某些部分可能看起來很明顯，但其價值在於這些部分是如何連接起來並建立起一個有效的代碼質量保證系統的。
- 代碼質量到底是什麼？
- 為什麼要關心代碼質量？
- 為您的團隊構建代碼質量保證體系確保代碼質量和透明度的版本控制工具可讀和可理解代碼的樣式指南通過功能測試提高代碼質量
- 如何測量測試
- 用戶界面測試
- 使用持續集成工具
- 後期代碼質量
- 案例研究
代碼質量到底是什麼？
代碼質量是一組不同的屬性和需求，由您的業務決定和確定優先級。以下是可用於確定它的主要屬性：
- 清晰：對於不是代碼創建者的人來說，閱讀和監督都很容易。如果很容易理解，那麼維護和擴展代碼就容易多了。不僅僅是計算機，人類也需要理解它。
- 可維護性：高質量的代碼並不複雜。任何使用代碼的人如果想做任何更改，都必須理解代碼的整個上下文。
- 文檔化：最好的事情是當代碼是自解釋的，但是總是建議在代碼中添加註釋來解釋它的角色和功能。它使沒有參與編寫代碼的人更容易理解和維護代碼。
- 重構：代碼格式需要一致，並遵循語言的編碼約定。這裡有一些代碼重構技巧。
- 測試良好：代碼的錯誤越少，質量就越高。徹底的測試會過濾掉關鍵的錯誤，確保軟件按照預期的方式工作。
- 可擴展：你收到的代碼必須是可擴展的。幾周後你不得不扔掉它，這真的不太好。
- 效率：高質量的代碼不會使用不必要的資源來執行所需的操作。
質量代碼不一定滿足上述所有屬性，但滿足的越多，質量就越高。這些需求更像是取決於項目特性的優先級列表。
為什麼要關心代碼質量？
偉大的作家寫的書有引人入勝的故事，很容易閱讀和理解。從某些方面來說，作者的工作類似於開發人員的工作。主要區別在於開發人員使用不同的行話。
由於作者的寫作必須易於閱讀和全面，所以軟件開發人員的代碼也應該如此。
我知道，當你在壓力下不得不在下一個截止日期前完成工作時，很難關注代碼質量，但是如果你想長遠考慮，你肯定需要生成可讀和可維護的代碼。以下是代碼質量重要的三個主要原因：
- 可讀性：使代碼更可讀，更容易理解，為每個人在項目上工作。讀和理解一個質量低劣的代碼要比寫它困難得多。
- 可維護性：維護和測試質量代碼更容易、更安全、更省時。
- 較低的技術債務：高質量的代碼可以加速長期的軟件開發，因為它可以重用，開發人員不必花那麼多時間修復舊的錯誤和拋光代碼。它還使新的項目成員更容易加入項目。
為您的團隊構建代碼質量保證體系
在這一部分中，我將向您展示如何使用版本控制、樣式指南和自動化測試來確保我們的代碼符合預定義的質量標準。
通過遵循這些方法，您可以輕鬆地複製我們的系統，並從根本上提高您的團隊生成的代碼質量。您只需執行以下步驟：
- 安裝程序版本控制
- 確定慣例
- 運行功能質量測試
一。版本控制工具，確保代碼質量和透明度
版本控制工具是我們系統的基礎。
最流行的版本控制工具是Git。它還提供了一個分支樣式的指南，稱為GitFlow，它支持團隊成員之間的無縫協作，並使擴展開發團隊變得容易。
它提供了一個易於跟蹤的系統，將活動產品與具有未發佈特性的不太穩定的開發人員分支分離開來。
當我們團隊的開發人員完成一個特性時，他/她會在GitHub上發送一個pull請求。這描述了請求的內容和詳細信息。
此係統確保沒有未查看的代碼將與主分支合併。代碼檢查很重要，您需要正確的工具來完成它。
以下是我們的流程：
- 一個團隊成員向開發分支發送一個pull請求。
- 這將出現在“準備審閱”部分中，等待項目成員審閱（同行審閱）。
- 團隊成員審查請求，如果它滿足需求，它將被合併到開發分支。
這是一個很好的控制版本和使每個人的工作完全透明的系統。Git有很多GUI擴展，比如支持Gitflow的GitKraken。在這裡您可以看到如何輕鬆地啟用它。
但是你如何決定代碼是否足夠好呢？
在下一部分中，我將向您展示跟蹤代碼質量的工具和可用於度量代碼質量的度量。
1。可讀和可理解代碼的樣式指南
樣式指南是最佳實踐和約定的集合。使用樣式指南可以確保每個開發人員的代碼看起來完全相同，從而使代碼更易於檢查和使用。
幸運的是，您不必創建自己的樣式指南。有許多免費的樣式指南，主要針對不同的編程語言和範圍：
公司：像Airbnb和Google這樣的酷公司已經創建併發布了他們自己的風格指南。這是Airbnb的JavaScript風格指南。
項目：公司內不同的項目或產品可能有不同的約定。我們並不推薦基於項目的風格指南，因為它使人們在項目之間切換變得更加困難。
使用linters自動測試代碼樣式
linter 是款式指南的一部分。它是一個小軟件，可以自動檢查代碼是否符合預定義的代碼約定規則。您不必手動檢查代碼庫來檢查樣式。
幾乎每種編程語言都有linter，僅舉幾個例子：
- JavaScript ESLint
- TypeScript TSlint
- Python pylint /flake8
- Sass/SCSS sass-lint
- Go golang lint
- Bash ShellCheck
您也可以在這裡查看我們自己的 JavaScript style guide here （儘管需要更新）。
許多代碼編輯器都支持可配置的linting，例如VSCode。這裡有一個如何設置自己的 linter的指南。
EditorConfig 幫助開發人員定義和維護不同編輯器和ide之間的一致編碼樣式。EditorConfig項目由一個用於定義編碼樣式的文件格式和一組文本編輯器插件組成，這些插件使編輯器能夠讀取文件格式並遵循定義的樣式。
3。通過功能測試提高代碼質量
當使用linter的樣式指南測試代碼的外觀時，功能質量測試顯示代碼是否實際工作。
這個簡單的金字塔顯示了一個測試過程的結構和你的努力方向。
一般來說，我們可以說您必須運行大量的單元測試，更少的集成測試，甚至更少的端到端測試。
通過單元測試，您可以通過模擬依賴項來檢查軟件的一個模塊。集成測試顯示了在端到端測試檢查整個客戶機-服務器循環時，不同組件如何協同工作。
對於運行單元和集成測試，可以使用以下工具：
- Mocha
- Jasmine
對於端到端測試，我們建議使用：
- Jasmine
- Karma (for angular)
- Protractor
- Cucumber
附加閱讀：Mobile Labs Inc在部署任何應用程序之前都會列出一個很酷的清單。
如何測量測試
衡量測試有效性的最佳方法是跟蹤測試覆蓋率。它顯示了測試算法所覆蓋的代碼的百分比。為了更好地理解，有必要分解測試覆蓋率：
- 語句覆蓋率（%）：測試期間執行的語句數除以所有語句
- 分支覆蓋率（%）：執行的條件數除以所有條件
- 函數覆蓋率（%）：執行的函數數除以所有函數
- 行覆蓋率（%）：測試期間運行的行數除以所有行數
Istanbul 爾是一個很酷的工具，用於測量JavaScript代碼庫的測試覆蓋率。
用戶界面測試
UI測試也可以自動化，但它需要更多的資源，特別是當組件正在更改時，因此應該重寫完整的測試環境。
自動用戶界面測試有很酷的應用程序：用於Android UI壓力測試的Monkey測試、用於跨瀏覽器測試的Saucelabs和用於更全面的端到端測試（包括用戶界面）的dragor。
- Monkey test for Android
- Saucelabs
- Protractor
使用持續集成工具
我們的理念是總是對我們正在構建的軟件的狀況有反饋。這就是圖中的持續集成。我們最喜歡的博主之一，Martin Fowler，明確了持續集成的定義。
“持續集成是一種軟件開發實踐，在這種實踐中，團隊成員經常集成他們的工作，通常每個人至少每天集成一次，導致每天進行多個集成。每個集成都由自動化構建（包括測試）進行驗證，以儘快檢測集成錯誤。”
馬丁·福勒
以下是我們的流程：
- 持續集成平臺將在代碼上運行linter。如果失敗了，這個過程將在此停止，開發人員必須修復與樣式相關的問題。
- 如果代碼按照計劃運行，它將運行功能測試並轉到下一步。
- 然後開始計算測試覆蓋率。如果它不符合預定義的閾值，它將失敗。
- 如果請求正在與主分支合併，那麼也應該部署它。
推薦工具：
- Shippable
- TravisCI
後期代碼質量
你真的不應該在產品上線後就放棄質量跟蹤。諸如Sentry和Newrelic之類的工具可以實時監控錯誤，這樣就不必要求用戶報告崩潰和錯誤，因為系統會自動通知您。你只需要在你的應用程序中添加一小段代碼。
工具：
- Sentry (can be integrated with Slack and GitHub)
- Newrelic
案例研究
“我們認為，儘可能避免技術債務是最好的辦法。通過代碼審查，確保代碼標準得到遵守，避免黑客攻擊，您可以及早發現許多問題。
很明顯，有時在項目的最後期限和里程碑到來時，你無法避免增加技術債務。那麼最好把所有的事情都記錄下來。我們保留一份文件，其中列出了所有問題，它們在哪裡，為什麼要這樣做，以及哪些可能的措施可以解決這些問題。這樣我們就可以跟蹤我們在哪裡看到的問題，以及什麼時候它在我們的腦海裡是新鮮的。
當涉及到提高代碼質量時，它會根據具體情況工作。有時候你不得不接受一些永遠無法解決的問題，在解決的時候記住它。其他時候，它可以被安排到未來的sprint中，以便在下一次需要查看該功能時進行修復。”
結論
就這樣。這就是您如何為您的團隊創建一個工作流，確保每個人的代碼遵循相同的樣式指南，並通過預定義的測試來檢查功能質量。
除了在發佈前測試代碼質量之外，您還需要監視用戶開始使用應用程序時發生的情況。
我們知道編寫沒有bug的代碼是不可能的，但是遵循上面提到的過程肯定會提高團隊代碼的質量。
原文：https://codingsans.com/blog/code-quality
本文：http://jiagoushi.pro/comprehensive-guide-code-quality-best-practices-and-tools
討論：請加入知識星球【首席架構師圈】或者微信圈子【首席架構師圈】
閱讀更多 首席架構師 的文章
