您好,欢迎来到12图资源库!分享精神,快乐你我!我们只是素材的搬运工!!
  • 首 页
  • 当前位置:首页 > 开发 > WEB开发 >
    软件开发工程师技术债务的残缺指南
    时间:2021-08-04 21:10 来源:网络整理 作者:网络 浏览:收藏 挑错 推荐 打印

    软件开发工程师技术债务的残缺指南

    【51CTO.com快译】债务是一个复杂的话题。而软件开发工程师需求了解什么是技术债务以及如何有效管理技术债务以减速软件开发进程。

    债务这个术语常常带有负面含义,而一提到债务,在人们脑海中常常会显现存款、医疗账单以及抵押存款这样的现象。但实践上,一些金融债务虚际上可以为人们提供协助。

    技术债务也是如此。技术债务(也称之为代码债务)是指开发团队加快交付今后能够需求重构的项目或功用时会发作的状况。关于开发团队来说,加快开发进程成为优先事项,而不是高质量的代码。

    与金融债务一样,技术债务能够会为组织带来损害或能够提供协助。为了明智地运用,软件工程师和团队指导者必须了解有多少技术债务并学会妥善管理。关于组织来说,这能够成为一项艰难的义务,尤其是当他们对技术债务的利害没有明白了解的时分。

    技术债务是一个隐喻性框架,可以用于思索在开发团队加快软件消费之后需求重构的细节。

    技术债务有哪些同义词?

    像大少数发明出来的术语一样,技术债务还有很多其他称号,它们基本上都意味着同一件事情。在议论技术债务时,人们能够还会看到诸如……

    技术债务(Tech debt):技术债务的简写或昵称。

    设计债务:与软件的设计元素有关的技术债务。

    代码债务:与顺序员必须重构的软件系统中的不良代码相关的技术债务。

    这些术语都有纤细的差别,但都属于更大的技术债务类别。

    如何在Scrum框架中运用技术债务以及如何处置它

    Scrum如今曾经成为软件开发人员在寻求以更有效的方式交付产品时运用的盛行框架。Scrum的一个关键准绳是事情是不可预测的:客户改动主意或常常出现新需求。这种对变化的开放,意味着组织在运用Scrum框架时能够会出现技术债务。

    Scrum培训师Stefan Wolpers对Scrum中两种不同类型的技术债务停止了剖析与阐述。

    首先是自动选择创立由不完美代码组成的短期处置方案,以便可以更快地交付产品。希冀开发团队会在初始发布之后并不断来改良代码质量。

    当开发团队发现有关他们试图处置的成绩的更多信息时,另一种类型的技术债务能够会出现。随着新需求的出现,以往有效的处置方案如今能够无法奏效。其代码需求调整和重构,这样就产生了一些技术债务。

    Wolpers指出,Scrum指南并没有给出任何关于如何增加技术债务的详细指点。正如他所说,Scrum指南并没有提供万能的处置方案。虽然如此,他也看法到技术债务的积聚是组织在展停业务时不可避免的一部分,并为Scrum团队来更好地处置他们基于代码的技术债务提供了六种办法。

    他说,Scrum团队应该:

    (1)优先思索技术债务的透明度。Wolpers表示,透明度使管理技术债务变得愈加复杂。他建议开发团队突出展现他们的技术债务的可视化,将其作为首要义务,并在每次召开的Sprint会议时期审查他们的技术债务需求。

    (2)跟踪技术债务。Wolpers建议对错误停止计数,并尽能够运用更深化的代码目的,如圈复杂度、代码掩盖率、SQALE评级以及规则。

    (3)快速、活期地偿还债务。与金融债务一样,当团队活期偿还时,技术债务就会失掉更好的管理。Wolpers表示,Scrum团队应该思索将15%~20%的资源分配给每个Sprint周期的重构代码和修复错误。

    (4)增加产品积压。组织的产品积压应该包括与偿还技术债务相关的义务。而组织将这些债务列入想要处置的成绩,将有助于避免债务被无视或遗忘。

    (5)调整对“完成”的定义。在到达可管理的技术债务的既定标准之前,不要将某事视为曾经完成。

    (6)标准顺序。为组织的团队如何处置添加实验或新功用(包括引入技术债务)制定一个可重复的公式。

    技术债务有哪些不同类型?

    技术债务可以采取许多不同的方式,但还有很多人关于这些差异停止讨论。

    而大少数专家都认同具有两种不同类型的技术债务:有意的和有意的。而这与Wolper将Scrum用户的自动和被动技术债务停止别离有些相似。

    当组织为了延长上市时间而选择在其代码中留出改良空间时,就会发作有意的技术债务(也称为成心或自动)。

    当代码质量在一段时间后需求改良时,就会发作有意的技术债务(也称为偶然的、过时的、被动的或有意的)。这能够是第一次消费不佳的结果,或许只是随着代码过时而自然需求更新。

    2014年宣布的一篇名为《走向技术债务本体论》的学术论文关于只要两种类型的技术债务的观念停止了反驳。该论文指出,假设技术债务有更详细的类别,组织将会失掉更好的效劳,因此论文提出了13种不同类型的技术债务,每种类型都包括这篇论文指出的详细成绩:

    架构债务

    积聚债务

    代码债务

    缺陷债务

    设计债务

    文件债务

    基础设备债务

    人员债务

    处置债务

    要求债务

    效劳债务

    测试自动化债务

    测试债务

    虽然这些债务分类办法还有其他细节,但最盛行的债务分类办法来自Martin Fowler的技术债务象限。与Ward Cunningham一样,Martin Fowler是矫捷软件开发宣言的17位作者之一。但是当谈到技术债务时,Fowler独自开发了他所谓的“技术债务象限”。

    Martin Fowler的技术债务象限是什么?

    2009年,Fowler对由Steve McConnel推行的有意和有意的技术债务的双重别离停止了纤细的修正。他以为人们​​用债务停止比喻就像是问错了成绩。

    Fowler并没有试图找出有关设计缺陷的技术成绩的答案,例如“这能否被视为技术债务?”,而是想知道这些软件系统产生的债务是莽撞的还是慎重的。这种区别,再加上“有意”或“有意”债务的概念,构成了Fowler所称的技术债务象限。

    这个象限产生四种不同类型的技术债务:

    莽撞和有意。

    莽撞和有意。

    慎重和有意。

    慎重和有意。

    有意债务发作在发明的选择中,有意债务发作在团队需求做出调整之后。但是,慎重债务和莽撞债务的区别愈加共同,这种分类赋予了技术债务象限的价值。慎重的技术债务来自一个知道本人在做什么的团队,而当他们做事过于草率时,就会产生莽撞的债务。

    能看出慎重和莽撞的区别吗?

    慎重的团队了解他们的举动,并且他们有意运用他们的技术债务。

    莽撞的团队只是将他们的软件系统视为疯狂购物的美国运通银行持卡人,将招致技术债务不断地积聚。

    Fowler指出,用债务比喻来解释象限中最复杂的部分是慎重和有意部分。而当一个团队知道他们在做什么并且在项目上做得很好但最终依然需求一些返工时,就会出现这种状况。

    (责任编辑:admin)