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

[[269501]]

停止產(chǎn)生新的質(zhì)量問題

無論手頭的軟件過去是如何編寫的，您都應(yīng)當(dāng)立即停止向該軟件引入新的質(zhì)量問題。

第1步：安裝Sonarlin

作為開發(fā)人員，請?jiān)谀畛Ｓ玫腎DE(如Eclipse)中安裝Sonarlin(請參見https://www.sonarlint.org/)。您會驚奇地發(fā)現(xiàn)：當(dāng)自己在編寫代碼時(shí)，它會識別出代碼中的質(zhì)量問題，并給出詳細(xì)的說明，進(jìn)而提供修復(fù)的正確方法。

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

第2步：在SonarQube中建立Quality Gates

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

時(shí)間都去哪兒了?

作為一個開發(fā)人員，您很可能會將大部分的時(shí)間花費(fèi)在閱讀代碼，并理清代碼的意圖上。在嘗試修復(fù)bug或?qū)崿F(xiàn)新功能的過程中，您是否會反復(fù)讀到相同的代碼?您肯定會認(rèn)為應(yīng)當(dāng)通過重構(gòu)，以提高代碼的可讀性。但是，當(dāng)您面對一個由數(shù)千個文件(例如Java的類)所組成的軟件應(yīng)用時(shí)，又該如何下手進(jìn)行代碼重構(gòu)呢?

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

第3步：只重構(gòu)頻繁變更的文件

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

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

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

Commits File

230 gr/kolaxis/Utils.java

220 gr/kolaxis/UserManager.java

210 gr/kolaxis/UserTemplate.java

根據(jù)實(shí)際的數(shù)據(jù)(本例來自版本控制系統(tǒng))，您可以協(xié)同自己的開發(fā)團(tuán)隊(duì)，針對哪些需要進(jìn)行重構(gòu)的文件做出明智的決定。

只有對代碼庫中變更最為頻繁的文件予以重構(gòu)，才能增加它們的易讀性，也就更容易被每一位開發(fā)人員所理解。同時(shí)，有了針對性的代碼重構(gòu)，開發(fā)人員閱讀代碼的時(shí)間花銷也會大幅降低，整個開發(fā)團(tuán)隊(duì)的生產(chǎn)力同樣會得到相應(yīng)的提升。

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

請不要浪費(fèi)時(shí)間測試那些長時(shí)間未曾被修改的成熟代碼。相反，您應(yīng)當(dāng)將重點(diǎn)放在測試頻繁變更代碼的質(zhì)量保證環(huán)節(jié)。為什么這樣說呢?原因如下：

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

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

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

當(dāng)您打開一個長時(shí)間未進(jìn)行更改的源文件時(shí)，不管它有多“難看”，您都要抵住對它進(jìn)行重構(gòu)的誘惑。舊的源代碼已經(jīng)經(jīng)受了一段時(shí)間的考驗(yàn)，已經(jīng)在生產(chǎn)環(huán)境中無故障地運(yùn)行了許久。因此，我們沒有必要再花費(fèi)開發(fā)的寶貴時(shí)間與精力，對已被證明為正確的成熟代碼進(jìn)行改動，除非您有非常充分的理由。

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

誰動了我的代碼?

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

相反，如果某一個開發(fā)者對組件執(zhí)行了大部分的提交工作(甚至可以稱他們?yōu)榻M件的所有者)，那么該組件的失敗可能性會比較低，而預(yù)計(jì)的質(zhì)量則會比較高。

第6步：關(guān)注小部分代碼的貢獻(xiàn)者

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

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

擴(kuò)展閱讀

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

• l Tornhill，“軟件設(shè)計(jì)透視-固定技術(shù)債務(wù)與行為代碼分析”，程序員實(shí)務(wù)(The Pragmatic Programmers)，2017
• l N. Nagappan, B. Murphy, and V.R. Basili, “組織結(jié)構(gòu)對軟件質(zhì)量的影響：一項(xiàng)實(shí)證案例的研究”，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, “別碰我的代碼!檢查代碼所有權(quán)對于軟件質(zhì)量的影響”，ACM，2011(https://www.microsoft.com/en-us/research/publication/dont-touch-my-code-examining-the-effects-of-ownership-on-software-quality/)

原文標(biāo)題：Improve the Quality of Your Software in 6 Steps，作者： Ioannis Kolaxis

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