停止产生新的质量问题
无论手头的软件过去是如何编写的，您都应当立即停止向该软件引入新的质量问题。
第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