代碼品質與安全 | 第一次使用SonarQube，我從中吸取到了什麼經驗和教訓？

本文轉載自創實資訊

在這篇文章中，我将分享我是如何知道SonarQube，以及作為團隊上司來使用它的故事。我将讓大家了解它是如何幫助我們改進代碼，并幫助我培養一個擁有清潔代碼的初級開發人員團隊。我将分享我們在學習如何使用這個工具的過程中所犯的錯誤，為跟我們處于同樣境況的人提供參考建議。

開發應用程式可能會是一項複雜的任務

我們都知道，作為一名開發人員，成長是一個永無止境的旅程。我們必須不斷學習新事物。就我個人而言，我是非常喜歡學習的，但有時我也會不知所措。回顧我的職業生涯之初，我意識到有多少東西等着我學習：現代JavaScript，ECMAScript，React，異步程式設計，CSS，Sass，flexbox，grids…這樣的例子不勝枚舉。随着經驗的積累，我開始深入研究函數式程式設計、JavaScript中的CSS、高階元件、性能分析等等。

最令我滿意的作為開發人員的一點，就是能夠一邊學習各種技術，一邊建構很酷的使用者體驗！這一直激勵我走得更遠，不斷深耕，并最終幫助我了解前端軟體的真正工作原理。

雖然學習的過程很有價值的，但掌握開發應用程式所需的所有語言和技術是很困難的。就我個人而言，我總覺得我缺少一個工具來幫助我将學習提升到一個新的水準——一個可以衡量我的代碼品質并指出潛在的錯誤、不良模式和漏洞的工具。但我很幸運。我身邊有一群才華橫溢的開發人員，他們能夠在代碼審查期間幫助我發現代碼中的缺陷。他們幫助我了解如何修複代碼，以及作為一名開發人員應該如何提升自我。

我是如何知道SonarQube的

兩年前，我成為一名前端工程經理，負責一個由六名前端開發人員組成的團隊。我很快意識到，團隊中的每個人都必須經曆與我相同的學習曆程，這讓我深刻體會到制作一個好的Web應用程式需要多麼嚴格的要求。不僅需要正确使用技術和工具，而且應用程式必須始終保持可維護性。如果考慮到每個人了解代碼都是根據自己的經驗來的，這就變得更加困難了。

為了達到這種嚴格程度，我們進行了代碼審查、團隊之間的知識共享同步，以及一個技術上司“委員會”來定義最佳實踐并確定團隊保持一緻。但就算采取了以上所有措施，我們的應用程式品質仍然存在很大差距。更困難的是，我們的開發人員分布在不同的團隊和城市。不過幸運的是，我們負責安全性、名額、工具和CI/CD設定的基礎團隊向我們推薦了SonarQube。

在安全團隊完成了配置後，我們添加了一個sonar.properties檔案來自動啟動執行個體并将分析包含在釋出過程中。那時，我們沒有談論産品将如何使用，它将如何工作，或者它背後的哲學是什麼。但是，在将SonarQube添加到開發工作流程中後，我們很快意識到它在我們流程中充當的不僅僅是安全門限。

與SonarQube的第一步

使用SonarQube的最初幾天充滿了很多情緒。有些開發人員感到驚慌失措。他們有部分人反對該工具，其他人認為有些規則是不正确的，他們比工具更清楚。但在這個不确定的時期，團隊聚在一起讨論不同規則的利弊。我們發現了為什麼避免幻數（magic number，用來标記檔案或者協定的格式）很重要，限制函數的認知複雜性，複雜性的正确極限是什麼等等。我們還讨論了前端特定的需求：我們真的應該把路由路徑設定為常量嗎？應該避免寫死值嗎？但這樣做适用于編碼風格嗎？

在團隊内部進行了數天的對話後，我們決定建立自己的品質檔案，這對我們來說很有意義。這樣，我們可以将最近的所有讨論整合到一個我們都可以共享和使用的團隊品質配置檔案中。我們都認為Sonar的分析提供了豐富的資訊，能夠幫助我們建立一個流程，用來解決它檢測到的問題。

該配置檔案使團隊對使用Sonar更有信心了。随着代碼庫對我們來說越來越清晰透明，我們發現了許多在拉取請求審查期間可能會遺漏的東西。此外，我們還讨論了每個問題背後的編碼規則。這讓初學者能夠更快地學習，因為在質疑是否應該解決這個問題前，他們首先必須了解規則存在的原因以及它試圖阻止什麼。

SonarQube在我們的團隊中迅速改進了什麼

我很快就明白了開發人員對自己編寫的代碼品質有多麼關心。事實上，我的團隊中沒有一個開發人員會忽視分析結果。即使在因為結果不夠好而感到沮喪時，開發人員也會立即采取行動來改善他們的拉取請求。我相信每個開發人員都希望傳遞高品質的代碼，隻需要給予正确的工具和适當的讨論空間。

有了SonarQube，我們就有了評估代碼品質所需的所有名額。我們知道哪些部分的代碼是清潔的，哪些部分則需要改進。該工具幫助我們與項目經理一起确定工作的優先級。他們可以通路結果，并能夠了解他們的産品是否存在風險。

我們還開始使用代碼異味頁面為新加入者建立入門工單（甚至添加到更小的Sprint中），這非常受歡迎。它讓新加入的人能夠從非常精确且易于測量的東西開始。

有了SonarQube的使用名額，我能夠與内部技術上司委員會分享我們的成果，并了解其他團隊如何使用它。我們以此為契機，在團隊之間共享了一組最佳實踐。

在使用SonarQube時，我們犯了哪些錯誤

在開始清潔代碼之旅的初期，我們決定Sonar隻用于提供資訊。這是一個巨大的錯誤！我們安裝了SonarQube，卻沒有對它的用途有足夠的了解。

我多希望我以前知道“邊寫邊清理”方法！直到我加入Sonar時，我才了解并發現它有多強大。顯然，當您有成百上千個錯誤、安全漏洞和代碼異味時，嘗試全部修複它們簡直是挑戰不可能。這就是“邊寫邊清理”的作用所在！

與其投入大量時間和精力來修複舊代碼，不如專注于寫清潔的新代碼。這樣，您就不會向代碼庫添加更多問題。

品質門限可以防止您合并不清潔的代碼，幫助您確定不會向代碼庫添加任何關鍵問題。同時，當您在編寫新代碼時，不可避免地會接觸到舊代碼。很簡單，因為在實作新功能的過程中，您要麼删除一些代碼(用新的代碼替換它)，要麼修改它以适應新功能的需要。平均而言，您每年會重寫20%的應用程式代碼。有了良好的設定和對工具的了解，提高應用程式的代碼品質就不再是一件苦差事。

請相信SonarQube！

在學習如何使用SonarQube的過程中，我們犯了很多錯誤。我們是一個由初級開發人員組成的團隊（我是一名初級工程經理），沒有使用清潔代碼解決方案的經驗。引入SonarQube對我們來說是一個建立強大技術基礎、進行許多有趣讨論的機會。它為團隊帶來了新的指導方針和名額，幫助我們在清潔代碼政策上與項目相關人員保持一緻。通過使用一組對我們有意義的規則來定義和執行品質配置檔案，我們提高了代碼的整體品質和一緻性。在個人層面上，SonarQube對我來說也是一個機會，可以把更多的時間和精力花在團隊的動态和氛圍上，而不是在技術方面。

在經過了多次嘗試、讨論和錯誤後，我們才弄清楚如何使用SonarQube。現在我在Sonar工作，我認識到品質門限和邊寫邊清理方法可以幫助我們的業務更進一步。但是，沒有人能在一帆風順中學習。是以，以下是我對準備開始使用SonarQube的開發人員或開發團隊的建議：

不要将SonarQube看作代碼的又一個統計資料，而是采用清潔代碼方法來幫助團隊獲得最佳結果。

利用品質門限來確定新代碼的清潔，并使開發人員對其編寫的代碼品質負責。

讨論并定義一個有意義的品質概要檔案，使用對您的團隊有意義的正确規則集。SonarWay是最好的首選開始方式。

最後，通過與所有相關人員共享名額，讓每個人從一開始就參與到清潔代碼的政策中來。

文章來源：https://www.sonarsource.com/blog/developing-an-application-can-be-a-complicated-task/