停止產(chǎn)生新的質(zhì)量問(wèn)題
無(wú)論手頭的軟件過(guò)去是如何編寫(xiě)的，您都應(yīng)當(dāng)立即停止向該軟件引入新的質(zhì)量問(wèn)題。
第1步：安裝Sonarlin
作為開(kāi)發(fā)人員，請(qǐng)?jiān)谀畛Ｓ玫腎DE(如Eclipse)中安裝Sonarlin(請(qǐng)參見(jiàn)https://www.sonarlint.org/)。您會(huì)驚奇地發(fā)現(xiàn)：當(dāng)自己在編寫(xiě)代碼時(shí)，它會(huì)識(shí)別出代碼中的質(zhì)量問(wèn)題，并給出詳細(xì)的說(shuō)明，進(jìn)而提供修復(fù)的正確方法。
就我個(gè)人而言，我在過(guò)去的一年中一直使用著Sonarlin，它持續(xù)給我指出代碼中的各種未被意識(shí)到的錯(cuò)誤，讓我成長(zhǎng)為一名更好的軟件開(kāi)發(fā)者。
第2步：在SonarQube中建立Quality Gates
如果您有一個(gè)開(kāi)發(fā)團(tuán)隊(duì)，我建議您通過(guò)制定一套質(zhì)量控制策略，來(lái)給每一次提交建立一種檢查源代碼中質(zhì)量問(wèn)題的自動(dòng)化方法，以防止任何問(wèn)題被合并到主線上。通常，您可以在SonarQube(請(qǐng)參見(jiàn)https://www.sonarqube.org/)中配置Quality Gates(請(qǐng)參見(jiàn)https://docs.sonarqube.org/display/SONAR/Quality+Gates)，為不同類(lèi)型的質(zhì)量問(wèn)題設(shè)置一個(gè)或多個(gè)閾值。例如：您可以在不引入任何新的關(guān)鍵或重大問(wèn)題的前提下，成功提交新的源代碼。
時(shí)間都去哪兒了?
作為一個(gè)開(kāi)發(fā)人員，您很可能會(huì)將大部分的時(shí)間花費(fèi)在閱讀代碼，并理清代碼的意圖上。在嘗試修復(fù)bug或?qū)崿F(xiàn)新功能的過(guò)程中，您是否會(huì)反復(fù)讀到相同的代碼?您肯定會(huì)認(rèn)為應(yīng)當(dāng)通過(guò)重構(gòu)，以提高代碼的可讀性。但是，當(dāng)您面對(duì)一個(gè)由數(shù)千個(gè)文件(例如Java的類(lèi))所組成的軟件應(yīng)用時(shí)，又該如何下手進(jìn)行代碼重構(gòu)呢?
通常情況下，縱然應(yīng)用程序由數(shù)千個(gè)文件所組成，我們的軟件開(kāi)發(fā)活動(dòng)一般也就集中在有限的某個(gè)文件集中。例如：對(duì)于我所維護(hù)的企業(yè)級(jí)應(yīng)用程序而言，雖然它有著一萬(wàn)多個(gè)源代碼文件，但是我的開(kāi)發(fā)活動(dòng)往往只集中在其中的十多個(gè)文件上，它們?cè)诿恳淮翁峤恢卸紩?huì)發(fā)生變化。
第3步：只重構(gòu)頻繁變更的文件
通過(guò)在自己的代碼庫(kù)里識(shí)別那些變更最為頻繁的文件，您會(huì)了解到開(kāi)發(fā)人員都將時(shí)間不知不覺(jué)地花費(fèi)到了何處。如果您正在使用Git作為自己的版本控制系統(tǒng)，那么就可以執(zhí)行以下的命令：
git log --format=format: --name-only | egrep -v '^$' | sort | uniq -c | sort -r > commits_per_file.txt
該命令將針對(duì)您的代碼庫(kù)進(jìn)行文件列表的排序打印，其中變更最為頻繁的文件(即具有***提交次數(shù)的)會(huì)被排在最前列，如下所示：
Commits File
230 gr/kolaxis/Utils.java
220 gr/kolaxis/UserManager.java
210 gr/kolaxis/UserTemplate.java
根據(jù)實(shí)際的數(shù)據(jù)(本例來(lái)自版本控制系統(tǒng))，您可以協(xié)同自己的開(kāi)發(fā)團(tuán)隊(duì)，針對(duì)哪些需要進(jìn)行重構(gòu)的文件做出明智的決定。
只有對(duì)代碼庫(kù)中變更最為頻繁的文件予以重構(gòu)，才能增加它們的易讀性，也就更容易被每一位開(kāi)發(fā)人員所理解。同時(shí)，有了針對(duì)性的代碼重構(gòu)，開(kāi)發(fā)人員閱讀代碼的時(shí)間花銷(xiāo)也會(huì)大幅降低，整個(gè)開(kāi)發(fā)團(tuán)隊(duì)的生產(chǎn)力同樣會(huì)得到相應(yīng)的提升。
第4步：將測(cè)試集中在頻繁變更的代碼上
請(qǐng)不要浪費(fèi)時(shí)間測(cè)試那些長(zhǎng)時(shí)間未曾被修改的成熟代碼。相反，您應(yīng)當(dāng)將重點(diǎn)放在測(cè)試頻繁變更代碼的質(zhì)量保證環(huán)節(jié)。為什么這樣說(shuō)呢?原因如下：
- 由于頻繁變化，它們包含了更多的軟件缺陷與安全風(fēng)險(xiǎn)，因此更需要打上各種補(bǔ)丁。
- 它們一般提供的是用戶常用的功能，因此對(duì)于其效果的改進(jìn)需求會(huì)與日俱增。
雖然我們可以通過(guò)調(diào)整測(cè)試套件，只測(cè)試那些頻繁變更的代碼，從而節(jié)省寶貴的交付時(shí)間。但是開(kāi)發(fā)人員也需要經(jīng)常捫心自問(wèn)：這些頻繁變更的代碼覆蓋率到底是多少?
第5步：不要觸摸舊的代碼!
當(dāng)您打開(kāi)一個(gè)長(zhǎng)時(shí)間未進(jìn)行更改的源文件時(shí)，不管它有多“難看”，您都要抵住對(duì)它進(jìn)行重構(gòu)的誘惑。舊的源代碼已經(jīng)經(jīng)受了一段時(shí)間的考驗(yàn)，已經(jīng)在生產(chǎn)環(huán)境中無(wú)故障地運(yùn)行了許久。因此，我們沒(méi)有必要再花費(fèi)開(kāi)發(fā)的寶貴時(shí)間與精力，對(duì)已被證明為正確的成熟代碼進(jìn)行改動(dòng)，除非您有非常充分的理由。
我個(gè)人認(rèn)為：對(duì)于舊代碼的任意修復(fù)，往往會(huì)引入一些意想不到的新bug。因此，“存在便是合理”，我們暫且對(duì)它們進(jìn)行擱置。當(dāng)然，凡事也并非絕對(duì)，此處的例外是“死代碼(dead code)”。即：過(guò)去曾經(jīng)為了開(kāi)發(fā)某個(gè)特性而提交過(guò)的，但是從未真正使用過(guò)的代碼。因此，如果您確信某段代碼確實(shí)沒(méi)有被調(diào)用過(guò)，那么就請(qǐng)刪掉它吧!通過(guò)刪除“死代碼”，每一位開(kāi)發(fā)人員都會(huì)更加容易地去瀏覽現(xiàn)有的代碼庫(kù)，同時(shí)也能減少軟件應(yīng)用的總體構(gòu)建時(shí)間，進(jìn)而節(jié)省開(kāi)發(fā)團(tuán)隊(duì)寶貴的交付時(shí)間。
誰(shuí)動(dòng)了我的代碼?
對(duì)于某個(gè)軟件應(yīng)用，您知道有多少開(kāi)發(fā)人員正工作在給定的組件上嗎?根據(jù)微軟的研究：“小部分代碼貢獻(xiàn)者(minor contributor)的數(shù)量，與發(fā)布前后的失敗率，有著較強(qiáng)的正相關(guān)性?！币簿褪钦f(shuō)，如果有許多開(kāi)發(fā)人員只是偶爾對(duì)源代碼做出了貢獻(xiàn)(增加小段新的程序)，而且每段代碼都只有少量的提交(例如低于整體提交的5%)，那么該組件就很可能會(huì)對(duì)整體質(zhì)量造成影響。
相反，如果某一個(gè)開(kāi)發(fā)者對(duì)組件執(zhí)行了大部分的提交工作(甚至可以稱他們?yōu)榻M件的所有者)，那么該組件的失敗可能性會(huì)比較低，而預(yù)計(jì)的質(zhì)量則會(huì)比較高。
第6步：關(guān)注小部分代碼的貢獻(xiàn)者
如下圖所示，通過(guò)對(duì)軟件應(yīng)用中的所有組件逐一識(shí)別出小部分代碼的貢獻(xiàn)者，進(jìn)而著重測(cè)試他們的代碼質(zhì)量，以減少軟件應(yīng)用中的bug。
因此，主要代碼貢獻(xiàn)者需要定期審查小部分代碼貢獻(xiàn)者提交上來(lái)的程序;而小部分代碼貢獻(xiàn)者則需要在進(jìn)行程序修改之前，主動(dòng)咨詢主要代碼貢獻(xiàn)者。
擴(kuò)展閱讀
如果您對(duì)上述提高軟件質(zhì)量的話題感興趣的話，請(qǐng)進(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)對(duì)軟件質(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)對(duì)于軟件質(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
