开发者提高软件质量的六个步骤

译文
开发 架构
本文向您介绍有助于提高软件质量的六个步骤,希望对您有所帮助。

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

[[269501]]

停止产生新的质量问题

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

第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作为自己的版本控制系统,那么就可以执行以下的命令:

  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。

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

扩展阅读

如果您对上述提高软件质量的话题感兴趣的话,请进一步阅读如下的资源与链接:

  • 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

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

责任编辑:华轩 来源: 51CTO
相关推荐

2021-10-21 08:00:00

开发技能技术

2012-03-01 15:55:42

2023-11-21 20:15:10

Git命令开发

2023-06-08 13:10:04

2022-08-17 10:14:17

数据中心能源消耗制冷

2019-01-07 07:57:27

物联网运营效率IOT

2023-06-26 23:32:11

人工智能Chat GPT工具

2014-08-20 13:59:13

Linux

2010-09-07 14:42:28

2021-06-22 14:53:35

零信任网络安全网络攻击

2012-03-07 09:41:01

Java

2012-08-27 09:31:35

创业程序员

2019-02-20 13:25:28

无边界网络网络安全网络攻击

2019-11-22 15:59:49

JavaScript开发工具

2017-05-17 17:22:28

开源软件开发代码

2021-04-25 08:00:00

开发软件质量保证

2013-07-09 14:53:06

编程

2011-12-17 22:48:30

Android

2010-10-28 09:52:51

iPhone OS苹果

2022-08-16 08:31:11

软件开发程序员
点赞
收藏

51CTO技术栈公众号