|
|
51CTO旗下网站
|
|
移动端

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

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

作者:陈峻编译来源:51CTO|2019-07-05 09:00

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

停止产生新的质量问题

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

第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】

【编辑推荐】

  1. 新工具一键安装Java环境!微软又双叒叕造福开发者
  2. Linus Torvalds 谈软件开发面临的硬件问题
  3. 权威调查:十大高级编程语言,开发人员必备!
  4. 印度***颗CPU横空出世:软件开发已开动
  5. 百度AI开发者大会现场李彦宏被泼水 淡定化解
【责任编辑:华轩 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

16招轻松掌握PPT技巧

16招轻松掌握PPT技巧

GET职场加薪技能
共16章 | 晒书包

289人订阅学习

20个局域网建设改造案例

20个局域网建设改造案例

网络搭建技巧
共20章 | 捷哥CCIE

645人订阅学习

WOT2019全球人工智能技术峰会

WOT2019全球人工智能技术峰会

通用技术、应用领域、企业赋能三大章节,13大技术专场,60+国内外一线人工智能精英大咖站台,分享人工智能的平台工具、算法模型、语音视觉等技术主题,助力人工智能落地。
共50章 | WOT峰会

0人订阅学习

读 书 +更多

网管员必读——超级网管经验谈

本书是一本以示例形式直接面向应用的网络管理图书。书中以大量示例和大量实用网络管理与故障排除经验介绍了当前网络管理工作的各主要方面。...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO播客