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

发表于:2021-9-03 09:48

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:zlmind    来源:简书

分享:
  停止产生新的质量问题
  无论手头的软件过去是如何编写的,您都应当立即停止向该软件引入新的质量问题。
  第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。
  因此,主要代码贡献者需要定期审查小部分代码贡献者提交上来的程序;而小部分代码贡献者则需要在进行程序修改之前,主动咨询主要代码贡献者。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号