【.com速递】您是否经常被客户抱怨软件应用有bug？您是否总是花费大量时间来实现新功能？如果您回答是的话，那么您的软件应用程序可能确实存在质量问题。本文向您介绍了帮助提高软件质量的六个步骤，希望对您有所帮助。停止制造新的质量问题无论手头的软件过去是如何编写的，您都应该立即停止给软件引入新的质量问题。第1步：安装Sonarlin作为开发人员，请在您最常用的IDE（例如Eclipse）中安装Sonarlin（请参阅https://www.sonarlint.org/）。您会感到惊讶：当您编写代码时，它会识别代码中的质量问题，给出详细说明，并提供修复这些问题的正确方法。就个人而言，过去一年我一直在使用Sonarlin，它继续指出我代码中各种未被注意到的错误，使我成为更好的软件开发人员。第2步：在SonarQube中建立质量关卡如果你有一个开发团队，我建议你通过制定一套质量控制策略来建立一个自动化的方法来检查每次提交的源代码中的质量问题，以防止任何问题被合并到主线。一般来说，你可以在SonarQube（参见https://www.sonarqube.org/）中配置QualityGates（参见https://docs.sonarqube.org/display/SONAR/Quality+Gates），针对不同类型的Quality问题设置一个或多个阈值。例如：您可以成功提交新的源代码，而不会引入任何新的关键或破坏性问题。时间都去哪儿了？作为一名开发人员，您可能会将大部分时间花在阅读代码和弄清楚其意图上。在尝试修复错误或实现新功能时，您是否一遍又一遍地阅读相同的代码？你一定认为重构应该是为了提高代码的可读性。然而，当你面对一个由数千个文件（比如Java类）组成的软件应用程序时，你如何开始代码重构呢？通常，即使应用程序由数千个文件组成，我们的软件开发活动通常也只关注有限的一组文件。举个例子：对于我维护的企业应用，虽然它有10000多个源代码文件，但我的开发活动往往只关注其中的十几个，而且在每一个commit中都会发生各种各样的事情。第3步：仅重构经常更改的文件通过识别您自己的代码库中最常更改的文件，您可以看到开发人员不知不觉地将时间花在了哪些地方。如果您使用Git作为您的版本控制系统，您可以执行以下命令：gitlog--format=format:--name-only|egrep-v'^$'|sort|uniq-c|sort-r>commits_per_file.txt这个命令会为你的代码库排序并打印文件列表，更改最频繁的文件（即提交次数最多的文件）会排在最前面，如下图：CommitsFile230gr/kolaxis/Utils.java220gr/kolaxis/UserManager.java210gr/kolaxis/UserTemplate.java根据实际数据（本例来自版本控制系统），可以配合自己的开发团队决定使用哪个文件需要重构是一个明智的决定。只有重构代码库中最常更改的文件才能增加它们的可读性，并使每个开发人员更容易理解它们。同时，通过针对性的代码重构，大大减少开发人员阅读代码的时间，整个开发团队的工作效率也会相应提高。第4步：将测试重点放在经常更改的代码上不要浪费时间测试长时间未修改的成熟代码。相反，您应该专注于测试频繁更改代码的质量保证方面。你为什么这么说？原因如下：由于修改频繁，软件缺陷和安全隐患较多，需要打补丁。它们通常提供用户常用的功能，因此对其效果的改进需求将与日俱增。虽然我们可以通过将测试套件调整为仅测试那些经常更改的代码来节省宝贵的交付时间。但开发者也需要时刻问自己：这些频繁改动的代码覆盖率是多少？第5步：不要碰旧代码！当你打开一个很久没有更改的源文件时，无论它有多“丑”，你都必须抵制重构它的诱惑。老源码经过一段时间的试用和测试，在生产中运行了很长时间没有问题。因此，我们不需要花费宝贵的开发时间和精力去修改已经被证明是正确的成熟代码，除非你有非常充分的理由。我个人认为对旧代码的任意修复经常会引入一些意想不到的新错误。因此，“存在即合理”，我们暂且搁置。当然，一切都不是绝对的，这里的例外是“死代码（deadcode）”。即：过去提交用于开发功能但从未实际使用过的代码。所以，如果你确定一段代码从未被调用，删除它！通过移除“死代码”，每个开发人员将更容易浏览现有的代码库，同时也会减少软件应用程序的整体构建时间，进而为开发团队节省宝贵的交付时间。谁动了我的代码？对于一个软件应用程序，您知道有多少开发人员在开发一个给定的组件吗？根据微软的研究：“次要贡献者的数量，发布前后与失败率有很强的正相关关系。”也就是说，如果许多开发人员偶尔对源代码做出贡献（添加小块新程序），并且每段代码只有少量提交（例如少于总体提交的5%），那么该组件是可能会对整体质量产生影响。相反，如果一个开发人员完成了组件的大部分提交工作（您甚至可以称他们为组件的所有者），那么该组件失败的可能性就会降低，并且预期质量会更高。第六步：关注一小部分代码的贡献者如下图所示，通过对软件应用中所有组件的一小部分代码的贡献者一一识别，然后重点测试他们的代码质量以减少软件应用程序中的错误。因此，主要代码贡献者需要定期审核少数代码贡献者提交的程序；少数代码贡献者在修改程序前需要主动咨询主要代码贡献者。进一步阅读如果您对上述提高软件质量的主题感兴趣，请进一步阅读以下资源和链接：lTornhill，“软件设计视角-固定技术债务和行为代码分析”，ThePragmaticProgrammers，2017lN.Nagappan、B.Murphy和V.R.Basili，“组织结构对软件质量的影响：实证案例研究”，ACM，2008(https://www.microsoft.com/en-us/research/publication/the-influence-of-organizational-structure-关于软件质量的经验案例研究/）。lBird、N.Nagappan、B.Murphy、H.Gall和P.Devanbu，“不要触摸我的代码！检查代码所有权对软件质量的影响”，ACM，2011(https://www.microsoft.com/en-us/research/publication/dont-touch-my-code-examining-the-effects-of-ownership-on-software-quality/)原标题：通过6个步骤提高软件质量，作者:IoannisKolaxis【翻译稿件，合作网站转载请注明原译者及出处.com】
