当前位置: 主页 > 建站知识 > 软件开发

软件开发质量管理-有助于提高软件质量的六个步骤,你知道吗?

发布时间:2023-06-22 16:10   浏览次数:次   作者:佚名

您是否常被客户投诉软件应用中的bug问题?您是否总要花费大量的时间来实现新的功能?如果您回答是Yes的话软件开发质量管理,那么,您的软件应用可能的确存在着质量方面的问题。本文向您介绍有助于提高软件质量的六个步骤,希望对您有所帮助。

农业项目的开发,运作及管理,农业市场分析_软件开发质量管理_医药管理系统的开发过程模型

停止产生新的质量问题

无论手头的软件过去是如何编写的,您都应当立即停止向该软件引入新的质量问题。

第1步:安装Sonarlin

作为开发人员,请在您最常用的IDE(如Eclipse)中安装Sonarlin(请参见)。您会惊奇地发现:当自己在编写代码时,它会识别出代码中的质量问题,并给出详细的说明,进而提供修复的正确方法。

就我个人而言,我在过去的一年中一直使用着Sonarlin,它持续给我指出代码中的各种未被意识到的错误,让我成长为一名更好的软件开发者。

农业项目的开发,运作及管理,农业市场分析_医药管理系统的开发过程模型_软件开发质量管理

第2步:在SonarQube中建立Quality Gates

如果您有一个开发团队,我建议您通过制定一套质量控制策略,来给每一次提交建立一种检查源代码中质量问题的自动化方法,以防止任何问题被合并到主线上。通常,您可以在SonarQube(请参见)中配置Quality Gates(请参见+Gates),为不同类型的质量问题设置一个或多个阈值。例如:您可以在不引入任何新的关键或重大问题的前提下,成功提交新的源代码。

农业项目的开发,运作及管理,农业市场分析_医药管理系统的开发过程模型_软件开发质量管理

时间都去哪儿了?

作为一个开发人员,您很可能会将大部分的时间花费在阅读代码,并理清代码的意图上。在尝试修复bug或实现新功能的过程中,您是否会反复读到相同的代码?您肯定会认为应当通过重构,以提高代码的可读性。但是,当您面对一个由数千个文件(例如Java的类)所组成的软件应用时,又该如何下手进行代码重构呢?

通常情况下,纵然应用程序由数千个文件所组成,我们的软件开发活动一般也就集中在有限的某个文件集中。例如:对于我所维护的企业级应用程序而言,虽然它有着一万多个源代码文件,但是我的开发活动往往只集中在其中的十多个文件上,它们在每一次提交中都会发生变化。

软件开发质量管理_医药管理系统的开发过程模型_农业项目的开发,运作及管理,农业市场分析

第3步:只重构频繁变更的文件

通过在自己的代码库里识别那些变更最为频繁的文件,您会了解到开发人员都将时间不知不觉地花费到了何处。如果您正在使用Git作为自己的版本控制系统,那么就可以执行以下的命令:

  1. 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。

软件开发质量管理_农业项目的开发,运作及管理,农业市场分析_医药管理系统的开发过程模型

因此软件开发质量管理,主要代码贡献者需要定期审查小部分代码贡献者提交上来的程序;而小部分代码贡献者则需要在进行程序修改之前,主动咨询主要代码贡献者。

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

医药管理系统的开发过程模型_软件开发质量管理_农业项目的开发,运作及管理,农业市场分析