【51CTO.com快譯】您是否常被客戶投訴軟件應用中的bug問題?您是否總要花費大量的時間來實現新的功能?如果您回答是Yes的話，那么，您的軟件應用可能的確存在著質量方面的問題。本文向您介紹有助于提高軟件質量的六個步驟，希望對您有所幫助。

[[269501]]

停止產生新的質量問題

無論手頭的軟件過去是如何編寫的，您都應當立即停止向該軟件引入新的質量問題。

第1步：安裝Sonarlin

作為開發人員，請在您最常用的IDE(如Eclipse)中安裝Sonarlin(請參見https://www.sonarlint.org/)。您會驚奇地發現：當自己在編寫代碼時，它會識別出代碼中的質量問題，并給出詳細的說明，進而提供修復的正確方法。

就我個人而言，我在過去的一年中一直使用著Sonarlin，它持續給我指出代碼中的各種未被意識到的錯誤，讓我成長為一名更好的軟件開發者。

第2步：在SonarQube中建立Quality Gates

如果您有一個開發團隊，我建議您通過制定一套質量控制策略，來給每一次提交建立一種檢查源代碼中質量問題的自動化方法，以防止任何問題被合并到主線上。通常，您可以在SonarQube(請參見https://www.sonarqube.org/)中配置Quality Gates(請參見https://docs.sonarqube.org/display/SONAR/Quality+Gates)，為不同類型的質量問題設置一個或多個閾值。例如：您可以在不引入任何新的關鍵或重大問題的前提下，成功提交新的源代碼。

時間都去哪兒了?

作為一個開發人員，您很可能會將大部分的時間花費在閱讀代碼，并理清代碼的意圖上。在嘗試修復bug或實現新功能的過程中，您是否會反復讀到相同的代碼?您肯定會認為應當通過重構，以提高代碼的可讀性。但是，當您面對一個由數千個文件(例如Java的類)所組成的軟件應用時，又該如何下手進行代碼重構呢?

通常情況下，縱然應用程序由數千個文件所組成，我們的軟件開發活動一般也就集中在有限的某個文件集中。例如：對于我所維護的企業級應用程序而言，雖然它有著一萬多個源代碼文件，但是我的開發活動往往只集中在其中的十多個文件上，它們在每一次提交中都會發生變化。

第3步：只重構頻繁變更的文件

通過在自己的代碼庫里識別那些變更最為頻繁的文件，您會了解到開發人員都將時間不知不覺地花費到了何處。如果您正在使用Git作為自己的版本控制系統，那么就可以執行以下的命令：

git log --format=format: --name-only | egrep -v '^$' | sort | uniq -c | sort -r > commits_per_file.txt 

該命令將針對您的代碼庫進行文件列表的排序打印，其中變更最為頻繁的文件(即具有***提交次數的)會被排在最前列，如下所示：

Commits File

230 gr/kolaxis/Utils.java

220 gr/kolaxis/UserManager.java

210 gr/kolaxis/UserTemplate.java

根據實際的數據(本例來自版本控制系統)，您可以協同自己的開發團隊，針對哪些需要進行重構的文件做出明智的決定。

只有對代碼庫中變更最為頻繁的文件予以重構，才能增加它們的易讀性，也就更容易被每一位開發人員所理解。同時，有了針對性的代碼重構，開發人員閱讀代碼的時間花銷也會大幅降低，整個開發團隊的生產力同樣會得到相應的提升。

第4步：將測試集中在頻繁變更的代碼上

請不要浪費時間測試那些長時間未曾被修改的成熟代碼。相反，您應當將重點放在測試頻繁變更代碼的質量保證環節。為什么這樣說呢?原因如下：

• 由于頻繁變化，它們包含了更多的軟件缺陷與安全風險，因此更需要打上各種補丁。
• 它們一般提供的是用戶常用的功能，因此對于其效果的改進需求會與日俱增。

雖然我們可以通過調整測試套件，只測試那些頻繁變更的代碼，從而節省寶貴的交付時間。但是開發人員也需要經常捫心自問：這些頻繁變更的代碼覆蓋率到底是多少?

第5步：不要觸摸舊的代碼!

當您打開一個長時間未進行更改的源文件時，不管它有多“難看”，您都要抵住對它進行重構的誘惑。舊的源代碼已經經受了一段時間的考驗，已經在生產環境中無故障地運行了許久。因此，我們沒有必要再花費開發的寶貴時間與精力，對已被證明為正確的成熟代碼進行改動，除非您有非常充分的理由。

我個人認為：對于舊代碼的任意修復，往往會引入一些意想不到的新bug。因此，“存在便是合理”，我們暫且對它們進行擱置。當然，凡事也并非絕對，此處的例外是“死代碼(dead code)”。即：過去曾經為了開發某個特性而提交過的，但是從未真正使用過的代碼。因此，如果您確信某段代碼確實沒有被調用過，那么就請刪掉它吧!通過刪除“死代碼”，每一位開發人員都會更加容易地去瀏覽現有的代碼庫，同時也能減少軟件應用的總體構建時間，進而節省開發團隊寶貴的交付時間。

誰動了我的代碼?

對于某個軟件應用，您知道有多少開發人員正工作在給定的組件上嗎?根據微軟的研究：“小部分代碼貢獻者(minor contributor)的數量，與發布前后的失敗率，有著較強的正相關性。”也就是說，如果有許多開發人員只是偶爾對源代碼做出了貢獻(增加小段新的程序)，而且每段代碼都只有少量的提交(例如低于整體提交的5%)，那么該組件就很可能會對整體質量造成影響。

相反，如果某一個開發者對組件執行了大部分的提交工作(甚至可以稱他們為組件的所有者)，那么該組件的失敗可能性會比較低，而預計的質量則會比較高。

第6步：關注小部分代碼的貢獻者

如下圖所示，通過對軟件應用中的所有組件逐一識別出小部分代碼的貢獻者，進而著重測試他們的代碼質量，以減少軟件應用中的bug。

因此，主要代碼貢獻者需要定期審查小部分代碼貢獻者提交上來的程序;而小部分代碼貢獻者則需要在進行程序修改之前，主動咨詢主要代碼貢獻者。

擴展閱讀

如果您對上述提高軟件質量的話題感興趣的話，請進一步閱讀如下的資源與鏈接：

• l Tornhill，“軟件設計透視-固定技術債務與行為代碼分析”，程序員實務(The Pragmatic Programmers)，2017
• l N. Nagappan, B. Murphy, and V.R. Basili, “組織結構對軟件質量的影響：一項實證案例的研究”，ACM，2008(https://www.microsoft.com/en-us/research/publication/the-influence-of-organizational-structure-on-software-quality-an-empirical-case-study/)。
• l Bird, N. Nagappan, B. Murphy, H. Gall, and P. Devanbu, “別碰我的代碼!檢查代碼所有權對于軟件質量的影響”，ACM，2011(https://www.microsoft.com/en-us/research/publication/dont-touch-my-code-examining-the-effects-of-ownership-on-software-quality/)

原文標題：Improve the Quality of Your Software in 6 Steps，作者： Ioannis Kolaxis

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】