停止產生新的質量問題
無論手頭的軟件過去是如何編寫的，您都應當立即停止向該軟件引入新的質量問題。
第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
