Paper1: Managing Technical Debt

与金融债务的比较

管理你的债务

不同角度的债务成本

总结

Paper2: Technical Debt: From Metaphor to Theory and Practice

组织技术债务状况

处理技术债务

统一理论？

在这个问题上

Paper3: 10 Years of Technical Debt Research and Practice: Past, Present, and Future

TD’s Past: Origins and First Research

TD’s Present: Better Understanding, the First Evidence, and New Practices

TD’s Future: New Perspectives and Well-Known Open Issues

Paper4：Technical and Nontechnical Prioritization Schema for Technical Debt: Voice of TD- Experienced Practitioners

Ubiquitous Awareness of TD

Conceptualizing TD Elusiveness and the InsighTD Survey

方法论

Prioritization Schema for TD Constructs

Alignment and Misalignment of Technical and Nontechnical Perspectives

Alignment of Perspectives on TD Causes and Payment Practices

Misalignment of Technical and Nontechnical Perspectives on TD Effects and Payment Avoidance

Paper1: Managing Technical Debt

1992年，沃德·坎宁安（WArD CUNNINGHAM）在OOPSLA 2上发表了一份报告，提出了技术债务的概念。他用不成熟的代码来定义它：“发布第一次代码就像欠债一样。”然而，技术债务并不局限于第一次编写代码。承担技术债务有很多方法和理由（不全是坏的）。

技术债务通常源于工程“最佳实践”与其他因素（发货日期、工具成本和可用工程师的技能等）之间的紧张关系。粗略地说，当工程师采取不符合最佳实践的捷径时，就会产生技术债务。这包括偷偷摸摸抽象，因为很难（或不可能）弄清楚如何“正确地做”，跳过或精简文档（在代码和外部文档中），使用晦涩或不完整的错误消息，因为它是很难创建更多信息，使用简单但缓慢的算法来实现代码，即使他们知道在生产中需要更好的算法，使用 void* 当你真的应该创建一个适当的联合*时，使用构建工具对于手头的系统不太适用，忽略良好的安全实践，不编写单元测试等等。承认吧——在你的职业生涯中，你们都做过一件或多件（或者可能全部）这些事情。（技术债务也可能被有意作为一种节省时间或金钱的策略；稍后会详细介绍。）

并非所有债务（无论是技术债务还是财务债务）都是坏账。我们中很少有人能付得起现金买房，如果我们知道如何偿还的话，举债买房在经济上并不是不负责任的。相比之下，在信用卡上为奢侈品充值时，明知你的薪水无法支付，通常会导致灾难。在原型中使用简单但缓慢的算法可能正是正确的路径，只要你有一个在代码发布之前如何更新代码的计划。这意味着在计划中留出时间，确保问题得到跟踪，这样它就不会在混乱中丢失，知道当你实现代码时，一个好的算法确实存在，在这种情况下可以工作，并且相信管理层会支持你。

理解、沟通和管理技术债务可以对系统的短期和长期成功产生巨大的影响。（请注意，尽管本文主要关注软件工程中的技术债务，但这些原则中的许多可以应用于其他技术学科。）

与金融债务的比较

与金融负债相比，进入金融负债通常有三个重要属性。首先，发放贷款的人希望最终偿还贷款。第二，你通常需要偿还利息，也就是说，你偿还的钱比你最初得到的要多。第三，如果你无法偿还，那么成本非常高，无论是宣布银行破产、失去房子，还是（如果你从错误的人那里借来的话）穿着休闲鞋从短码头上走下来。

技术债务在某些方面相似，但在其他方面有所不同。尽管您不必按任何固定的时间表偿还债务（有些债务可能永远不需要偿还），但您通常必须偿还（即重写代码或以其他方式解决问题）部分对您或您的客户产生重大影响。每当您或其他任何人（支持台工作人员、未来的程序员、客户等）由于错误、性能问题、莫名其妙的错误功能、花时间研究出现问题的时间而延迟使用您的系统时，就会产生“兴趣” 当系统可以给出更明确的错误消息时，等等。未能解决问题可能会导致系统彻底崩溃——客户放弃并转向别处，系统变得如此缓慢和脆弱以至于必须从头开始重写，或者在极端情况下公司被迫关门 .

也有一些显着差异。也许最有害的是，承担技术债务的人不一定是必须偿还的人——事实上，大多数时候，承担债务的人可以将成本转嫁给其他人，这鼓励承担债务。太多的开发人员不维护自己的代码。许多公司制定了一项政策，即软件从由最好的程序员组成的开发模式转变为由二级工程师组成的维护模式（他们的薪水较低，但工作往往比顶级团队困难得多）。有时，甚至组织中的任何人都没有支付利息：必须支付的是用户。与长期可维护性相比，开发人员在实施速度上获得的回报更多，并且可能在支付实际成本之前已经转移到不同的项目或公司。这使最初的开发人员很少有动力在第一次就做好这项工作。

与金融债务不同，技术债务几乎不需要全部偿还。大多数（可能是所有）生产系统都有缺陷，不会对最终系统的可用性或长期可维护性产生重大影响。很少有系统在源代码的某处没有 TODO 或 FIXME 或 XXX 注释。请注意，偿还技术债务的成本是以重写或重构代码或以其他方式解决问题所需的工程时间的形式出现的。如果您最终产生的利息低于偿还债务的成本，那么首先偿还债务是没有意义的。问题在于，很难事先知道哪些债务最终成本最高。

例如，当 U.C.伯克利的 CalMail 系统于 2011 年 11 月出现故障，该问题可追溯到延迟维护——特别是延迟更新系统的决定，即使已知系统已接近容量。 5 RAID 中的一个磁盘死了，紧接着又死了第二个，重建阵列的成本大大降低了容量，从而造成了危机。在决定接受多少技术债务时，需要考虑墨菲定律。在 CalMail 案例中，预计基础设计中会出现个别硬件故障，但在历史上的高使用高峰期间发生的多个故障造成了无法快速解决的情况。根据伯克利信息技术副校长兼首席信息官谢尔顿瓦格纳的说法，“鉴于我们计划迁移到新技术，我决定不花费 12 个月的时间来升级 CalMail 软件。鉴于预算情况，我们试图保持谨慎，（但）回想起来，投资于存储升级本来是件好事，因此我们可能避免了这场危机。”这是一个故意承担技术债务但结果却是一场糟糕的赌博的案例。如果该系统在 12 个月的窗口中存活下来，学校可能会在预算紧缩期间节省 100 万美元。

有一种说法，大意是工程中存在三个变量：时间、功能和资源——选择两个。事实上，还有第四个变量：债务。在这四个变量中，您可以设置其中的任何三个，但您不能设置全部四个；必须付出一些东西，而债务通常是等式中的自由变量。债务起初似乎是“免费的”，但技术债务往往会建立在自身之上。如果获得债务涉及以增加维护和扩展系统的努力形式的利息，那么当您承担债务时，维护和扩展会变得更加困难并且需要更长的时间。这是债务崩溃的一种形式：如果你所有的“收入”（以努力的形式）都花在偿还利息上，而没有留下任何东西来推动系统向前发展，那么这个系统就会陷入困境。如果生产力以每天生成的代码行数来衡量，这一点尤其明显，这种衡量标准应该归入地狱之火。您没有太多选择：加倍努力（雇用更多工程师）、放弃系统并继续前进，或者破产。从这个意义上说，技术债务的利息实际上是复利，或者换一种说法：如果你不继续偿还债务，那么随着时间的推移，还款额会增加。

理解、沟通和管理技术债务可以对系统的短期和长期成功产生巨大影响。

考虑这些其他有趣的比较。 Construx Software 的首席执行官兼首席软件工程师 Steve McConnell 区分了无意债务和有意债务，后者又分为短期（战术）和长期（战略）债务。 6 他还指出，当系统接近使用寿命时，产生的债务变得更具吸引力，因为当系统退役时，所有债务都将被偿还。他还对如何将技术债务的概念传达给非技术人员提出了一些有趣的观察，部分是通过在跟踪系统中维护“债务积压”并将其以美元而不是更以技术为导向的形式公开。

在一个稍微不同的分析中，软件设计师 Martin Fowler 在两个轴上分解技术债务：鲁莽/谨慎和故意/无意。 3 他将不计后果的债务描述为“我们没有时间进行设计”，将不计后果的债务描述为“什么是分层？” 和谨慎 - 深思熟虑，因为“我们必须立即发货并处理后果。” 这暴露了第四类技术债务，它不容易映射到财务模型：谨慎-无意，他将其描述为“现在我们知道我们应该如何去做”。

另一个引起一些人共鸣的技术债务分析是，管理技术债务是管理技术领域风险的一种方式。软件顾问史蒂夫弗里曼通过将技术债务与未对冲（或“裸”）看涨期权进行比较来讨论这一点。 4 任何一种情况（风险或未对冲的看涨期权）都可能导致永远不需要偿还债务；确实，通过适当的风险可以赚大钱。然而，裸电话也可能失去所有价值——本质上，风险是无限的。这并不经常发生（大多数时候，当你输了，你只损失了一部分钱，而不是全部），但它可能会发生，就像错误选择技术债务会导致灾难一样。

到目前为止，我们一直在谈论技术债务，就好像它是编码员独有的。这远非事实。例如，运营部门会产生自己的债务。避免磁盘阵列升级是技术债务和财务成本之间的权衡。在向机房添加新的、更热的设备时未考虑电源和冷却要求是一种债务。未能使简单但繁琐的手动流程自动化是一种债务。另一个例子是，系统管理员既没有（因为缺乏愿望、灵感或时间）记录他们支持的系统，也没有在休假前培训过同事。在这些与代码无关的情况下，技术债务与风险管理的比较通常更加明显：你打赌你不会耗尽磁盘空间或带宽，你不会有一个超级热的日子，你的系统不会变成如此成功以至于手动过程成为瓶颈，或者当您在马丘比丘时不会出现任何问题。

某些人员配备问题可能导致另一种形式的技术债务：系统的某些部分只有一个人才能理解。有时会发生这种情况，因为员工分散得太少，但也可能是由缺乏安全感的人造成的，他们认为如果他们把其他人都蒙在鼓里，那么他们将是不可或缺的。当然，问题是每个人最终都会继续前进。

管理你的债务

技术债务是不可避免的。问题不是消除债务，而是管理它。当一个项目开始时，团队几乎从来没有完全掌握问题的全部。这是软件开发瀑布模型失败的根源，该模型假定所有需求都可以在设计开始之前完成，而设计又可以在系统实施之前完成，等等。这个论点似乎很好：随着系统的开发，进行更改的成本呈指数级上升，因此最好的方法是在继续之前完成早期阶段。现实情况是需求总是在变化（“需求流失”）。通常最好有一个工作原型（即使它不完整或不完美），这样您和客户就可以开始获得系统经验。这就是敏捷编程背后的哲学，它接受一些技术债务是不可避免的，但也要求一个补救过程（“变革计划”）。

然而，尽管技术债务可能是必要的，但重要的是及时偿还其战略部分。随着时间的推移，程序员转到了其他公司，同意各种妥协的人也转到了其他项目，取而代之的是其他不这么看的人。未能为初始原型编写文档（内部和外部）可能是一个很好的权衡，但时间越长，编写起来就越困难——如果仅仅是因为人类记忆是短暂的，并且如果你向大多数人展示他们一年前编写的代码，他们将不得不研究它以记住他们为什么这样做。旨在具有有限生命周期的代码可能不受这些问题的影响，但许多短期“原型”最终会交付给客户。不幸的是，Fred Brooks 在 The Mythical Man-Month 中的声明：“计划扔掉一个；无论如何，你会的，” 1 似乎经常被损坏为，“让你的原型可交付；无论如何，它会的。”这两种说法并不矛盾。

同样重要的是，某些形式的技术债务非常昂贵，应尽可能完全避免。安全是一个走捷径可能导致灾难的领域。您永远不想说，“我们今天使用明文密码，但我们总有一天会回来并将其更改为质询-响应”，除了您不会看到的非常早期的原型之外的任何东西。如果它被意外部署，这是一个灾难的秘诀。您还希望避免在代码中加入“赌上你的公司”的捷径。如果由于某种原因您别无选择（例如，因为在开发过程中其他工程师必须编写与您的代码交互的代码，而您不能让他们等待），请记录“必须在发布前偿还的债务” 。” 令人惊讶的是，如果不写下来，忘记这些事情是多么容易。

发布周期可以对技术债务的获得和处置率产生相当大的影响。现代的“早期和经常发布”趋势，尤其是在基于 Web 的服务的背景下，使得承担技术债务变得更加容易，但也使得解决这些债务变得更加容易。如果管理得当，这可能是一件好事——提早承担债务可以让您更早地发布更多功能，让客户立即获得反馈，从而使产品对用户需求的响应速度更快。然而，如果这笔债务没有及时还清，它的复合速度也会更快，系统可能会以真正可怕的速度陷入困境。特别是基于 Web 的服务的另一面是，一个正确但低效的解决方案实际上会花费您的公司更多的钱——例如，以服务器场租赁费的形式。幸运的是，这使得债务很容易转化为美元，非技术利益相关者通常会发现这比关于可维护性的断言更容易理解。

并非所有技术债务都是程序员懒惰的结果。有些是由管理层或其他部门强加的，尤其是当他们不了解这种债务的危害性时。客户通常购买功能，而不是长期可维护性，因此营销部门经常鼓励工程部门继续进行下一个伟大的事情，而不是花费必要的时间来整合、清理和记录现有系统。对他们来说，采取这些步骤是不必要的成本——毕竟，系统在今天仍然有效，那么为什么工程需要花时间给百合镀金呢？技术债务还有另一个方面需要考虑：它以多种方式发生并且持续存在。当然，它可以来自设计或实施阶段，但也可以发生在运营阶段。例如，计算机系统可能已经设计和安装了 UPS（不间断电源），但延迟维护（以未能测试这些单元和更换电池的形式）可能会使它们变得无用。指定的磁盘阵列可能就足够了，但随着系统的增长，它们必须升级。当试图从现金拮据的管理层提取资金以升级从他们的角度来看可以正常工作的东西时，这可能尤其困难。

管理经常帮助和教唆这个问题。如果股东有足够的耐心来奖励长期的价值创造，那么当前“股东价值”的商业口号就可以了。取而代之的趋势是每季度而不是十年来思考，这给组织中的每个人带来了巨大的压力，无论长期成本如何，都要尽可能快地生产（如旧哀叹所示， “永远没有时间把它做好，但总有时间把它重新做一遍”）。将成本推到未来被认为是一个很好的策略。这强烈鼓励承担技术债务。这方面的一个指标是工程永远处于“紧缩模式”而不是谨慎使用紧缩。有多少公司在其网站和企业价值观声明中宣传“家庭友好”，同时鼓励员工每周工作 60 小时，惩罚每周工作 40 小时然后回家回家的“懒鬼”？在这些环境中，几乎不可能避免承担不适当的技术债务。

这并不是说管理总是错误的。有适当的时间来累积债务。如果我的孩子需要接受重症治疗，我不会仅仅因为这意味着要承担债务而拒绝，即使偿还费用会很昂贵。同样，管理层对客户、员工和（是的）投资者负有责任，有时会提出令人不快的要求。睁大眼睛以负责任的方式承担债务并不是一件坏事。加州大学伯克利的 CIO 下了一个赌注，结果是错误的，但它可能是一个成功的赌注。他知道自己成功了，当屋顶塌陷时，他对问题负责。困难在于管理层不了解他们所承担的债务，或者太容易和太频繁地承担债务，没有计划还钱。在过去的工作中，我认为我们需要更多的时间来建立一个系统，但当我们的缺陷率很高时才被管理层指责，这直接归因于人为地缩短了我的判断力。在这种情况下，管理层不了解债务，反而忽视警告，然后在问题出现时不承担责任。

不同角度的债务成本

技术债务影响每个人，但方式不同。这是管理债务问题的一部分——即使你从自己的角度理解它，也有其他合法的方式来看待它。

Customers. 在这件事上，客户似乎是最终的恶棍（和受害者）。毕竟，如果他们更有耐心，如果他们对产品的要求更少，并给公司更多的时间在第一时间把工作做好，那么这一切都不会发生（或者可能不会）。诚然，客户有时会更多地关注功能（遗憾的是，有时会关注营销绒毛），而不是长期可维护性、安全性和可靠性，但他们是受害最严重的人。当移动网络中断时，当他们无法按时提交工作时，当他们的公司因为与软件作斗争而失去业务时，他们就会付费。归根结底，这一切都是为了满足客户的需求，而客户需要能够工作、他们可以理解、可以维护和扩展、可以支持以及（最终）他们喜欢使用的软件。如果不通过整个流程管理各个级别的技术债务，就不可能发生这种情况，但客户很少能够控制债务的管理方式。值得注意的是，为定制解决方案付费的客户通常比购买“现成”软件的客户拥有更多的控制权，后者在很大程度上必须使用所提供的软件。同时，当您为特定客户构建软件时，您可能能够协商“债务偿还”版本（可能不使用该术语）。

Help Desk. 那些在帮助台上工作的人应该在天堂或偶尔在地狱中获得一个特殊的位置。客户很少打电话说他们有多开心；他们通常有一个相当不同的议程。服务台人员几乎承受着技术债务的方方面面：界面设计不佳、文档不良或不存在、算法缓慢等。此外，似乎不会直接影响他们的事情（例如代码本身的晦涩难懂） ) 会产生间接影响：解决问题的时间越长，客户越烦躁。尽管服务台是客户对内部流程的主要输入，但服务台通常无法直接联系能够解决问题的人。

Operations. 在以服务为导向的环境中，运营人员（那些携带蜂鸣器 24/7 并且必须保持一切正常工作的人）往往是前线的炮灰；他们可以将大部分时间花在为其他人在未咨询他们的情况下做出的决定上。有时他们会查看代码，有时则不会。无论如何，他们都会查看文档——如果它存在的话。（最小的）好消息是，只要他们能够提出可接受的解决方法，他们就可以将问题转交给维护人员。 DevOps 运动的兴起——运维人员需要在周期早期与开发人员合作以确保产品可靠、可维护和易于理解的概念——是一个积极的发展。这是减少长期技术债务的好方法，应该大力鼓励。

Engineers. 工程师分为两种角色：编写代码的开发人员和必须修复、扩展或以其他方式维护代码的人员（他们可能是相同的工程师，但在许多地方他们不是）。乍一看，最初的开发人员似乎是技术债务的主要创造者，他们确实有强烈的债务动机，但正如我们所见，它可能来自多个来源。在早期，技术债务几乎是无形的，因为利息还没有开始到期。做一个快速的、功能强大的初始实现会让程序员看起来很好，但代价是阻碍后来加入团队的工程师。在某些情况下，如果这些程序员维护成熟代码的经验有限，他们甚至可能没有意识到他们正在承担债务。出于这个原因，一个能够生成可维护代码的平均速度、稳定、经验丰富的程序员可能是一个更好的长期生产者，并且最终是一个更高质量的工程师，而不是一个可以一次跳跃高原型但从未有过的“超级程序员”。维护成熟的代码。

Marketing. 这些面向客户的人往往不得不首当其冲地受到客户的不满。他们通常是最努力缩短产品开发时间的人，因为他们受到销售和客户的压力，要求尽快提供新功能。然而，当该新功能在现场无法正常工作时，它们也是火线错误一侧的功能。此外，快速交付新功能的压力通常意味着以后的功能将需要更长的时间来生产。伟大的营销人员明白这一点，但通常这不是一个适合营销世界模型的概念。

Management. 有好的管理，也有不好的管理。良好的管理理解风险管理并平衡公司所有部门的需求。糟糕的管理往往有利于单个部门而损害其他部门。如果偏爱的部门是营销或销售部门，管理层将倾向于在不了解成本的情况下承担技术债务。然而，管理层也付出了代价。 “没有坏宣传这回事”这句话是不正确的，尤其是当你的公司似乎陷入困境时。管理层应该毫不费力地接受管理金融债务的概念。管理技术债务也对他们有利。

总结

技术债务可以被描述为所有在今天节省资金或加快进度的捷径，但有可能在未来（通常不清楚）未来可能会花钱或减慢进度。这是不可避免的，只要管理得当，它甚至可能是一件好事，但这可能很棘手：它来自多种原因，通常具有难以预测的影响，并且通常涉及到未来会发生什么的赌博未来。管理技术债务的大部分内容与风险管理相同，并且可以应用类似的技术。如果技术债务得不到管理，那么它会随着时间的推移而增加，可能直到危机发生。

技术债务可以通过多种方式来看待，并且可能由组织的各个级别引起。只有在各级的协助和理解下，才能妥善管理。特别重要的是帮助非技术方了解债务管理不善可能产生的成本。

Paper2: Technical Debt: From Metaphor to Theory and Practice

软件开发中技术债务的比喻是在 20 年前由 Ward Cunningham 引入的，目的是向非技术产品利益相关者解释我们现在所说的“重构”的必要性。从那以后，它得到了改进和扩展，特别是史蒂夫·麦康奈尔的分类法，马丁·福勒的四个象限，以及吉姆·海史密斯和他来自 Cutter Consortium 的同事们的技术债务对总拥有成本影响的模型。

从最初的描述——“我们推迟使它正确的代码不完全正确”——各种人使用技术“债务”的比喻来描述许多其他类型的债务或软件开发的弊端，广泛地包括任何阻碍部署、销售或发展软件系统或任何增加软件开发努力所遭受的摩擦的事情：测试债务、人员债务、架构债务、需求债务、文档债务，或者只是无定形的、无所不包的软件债务。因此，软件开发中技术债务的概念最近变得有些淡化。新的需求、功能或特性是否尚未实现“需求债务”？我们是否将推迟新功能的开发称为“计划债务”？这个比喻正在失去一些力量。

此外，一旦我们确定了诸如静态代码分析器之类的工具来帮助我们识别技术债务，就有将其等同于我们的工具可以检测到的任何东西的危险。这种方法导致留下大量工具无法检测到的潜在技术债务，例如结构或架构债务或技术差距。技术上的差距尤其令人感兴趣，因为产生的债务不是最初做出错误选择的结果，而是环境演变的结果——时间的流逝——所以回想起来，选择并不完全正确。在这种情况下，技术债务是由于外部事件造成的：技术过时、环境变化、商业上的快速成功、新技术和更好的技术的出现等等——换句话说，自然软件老化和进化的无形方面。你甚至可以争辩说，“镀金”一种架构设计，使系统比它实际需要的更灵活和适应性，如果这种增加的灵活性阻碍了未来的发展而没有被实际利用，这可能是一种技术债务。

组织技术债务状况

为了取得一些进展，我们需要超越债务这一“修辞概念”。我们需要更好地定义什么构成技术债务，以及一些能让我们推理各种技术债务的观点或观点。总之，我们需要一个理论基础。

图 1 显示了技术债务环境的可能组织结构——或者更确切地说，是从给定状态进行的软件改进。我们可以区分可见元素，例如要添加的新功能和要修复的缺陷，以及不可见元素（或者更确切地说，那些仅对软件开发人员可见的元素）。我们可以看到，在左边，我们主要处理进化或其挑战，而在右边，我们正在处理内部和外部的质量问题。我们建议将债务限制在无形的元素上——即矩形框中的元素，包括进化和质量的无形方面。

处理技术债务

大多数作者同意技术债务的主要原因是进度压力。然而，在图片的右侧，当债务与质量和可维护性问题相关时，其他原因变得可能，例如粗心、缺乏教育、流程不良、质量验证不系统或基本无能。

因为他们使用迭代开发过程，许多敏捷团队似乎相信他们完全不受技术债务的影响。尽管迭代提供了及时偿还债务的机会，但相反的情况经常发生。开发和交付非常迅速，没有时间进行适当的设计或反思长期，缺乏严谨或系统的测试（包括自动化测试）导致一些敏捷项目很快陷入巨额债务。事实上，与任何老式的瀑布式项目相比，此类债务的增加速度要快得多。但归根结底，这一切都取决于选择：在上市时间至关重要的情况下，债务实际上可能是一项不错的投资，但必须时刻注意这笔债务以及它将给开发团队带来的更大摩擦，因为坎宁安建议。

那么我们如何解决技术债务，或者至少避免积累太多技术债务呢？第一步是意识：识别债务及其原因。下一步是明确管理此债务，这包括在发布和迭代计划期间将与债务相关的任务与其他“要做的事情”一起列出在一个共同的积压工作中。图 2 说明了如何将这些元素组织在一个待办事项列表中。元素区域的颜色调和了四种可能的改进——未来要增加价值的任务，例如添加新功能（绿色）或对架构进行投资（黄色），并减少对价值的负面影响缺陷（红色）或技术债务（黑色）。

图2. 积压中的四种颜色。要素领域协调了四种可能的改进——未来要增加价值的任务，例如添加新功能（绿色）或投资架构（黄色），以及减少缺陷对价值的负面影响（红色）或技术债务（黑色）。

项目积压通常只包含绿色元素；一些技术从业者牢记黄色元素。红色元素出现在其他地方，可能在缺陷数据库中，黑色元素无处可寻，但它们越来越削弱开发，降低速度。

然而，重要的是要记住，技术债务不仅与代码和代码质量有关。代码分析工具会识别少量的黑色元素。因此，代码分析工具不足以识别技术债务：通常情况下，技术债务与代码及其内在品质无关，而是与结构或架构选择或技术差距有关。没有工具会透露，两年前，团队应该使用一些工具来国际化和本地化代码。

架构在大型系统的开发中以及其他开发活动中发挥着重要作用，例如文档和测试（通常缺乏）。这些活动会显着增加债务，因此是图 1 中技术债务状况的一部分。代码分析只会处理方框的右侧。专业精神、勤奋、奉献精神和工艺肯定会有所帮助，但它们并不是减少技术债务的关键决定因素。

统一理论？

Kevin Sullivan 建议，解决技术债务的简单模型将软件开发工作表示为一系列更改，其中大部分是改进。在给定的时间点，过去的一组更改定义了软件的当前状态。其中一些过去的变化是引发当前债务的事件：从当前的角度来看，变化或其实施方式并不完全正确。

软件开发组织面临的主要问题是如何决定未来的变化：软件系统应该经历什么样的演变，以什么样的顺序？在大多数情况下，这种演变受到成本的限制：在外部利益相关者看来，可用于进行这些改变的资源很可能是由价值驱动的。

从添加新功能和适应新技术到修复缺陷和提高质量，无论是内在的还是外在的，关于应用哪些变更顺序的决策过程可能是整个领域的主要协调点，如图 1 所示。因为这个决策过程是关于平衡成本和价值的，所以经济或金融模型可能会成为整个景观背后的统一概念。一些已经在一定程度上进行了探索：

• 产品的净现值 (NPV)，来自金融界；

• 机会成本;

• 实物期权分析（ROA）或估值；

• IT 系统的总拥有成本 (TCO)。

这四种模型在最近的 ICSE 技术债务研讨会上进行了讨论，其中一种 (NPV) 提供了最大的希望：它比机会成本更正式，比 TCO 更简单且专有性更低，而 ROA 可以被视为对净现值。如前所述，TCO 存在通过引入与软件开发（部署、运营和支持）无关的元素来稀释技术债务的危险。

技术债务不应与添加新功能或修复缺陷分开处理，即使这些不包括在此处提出的债务定义中。挑战在于用与成本和价值（随着时间）相关的变化序列来表达所有软件开发活动。不幸的是，这些变化并不是独立的。它们的相互依赖发挥了重要作用——正如 Mark Denne 和 Jane Cleland-Huang 所表明的那样，特别是可见的特征取决于不太明显的建筑方面。

从这个新的角度来看，系统在给定时间点的技术债务可以定义为延迟投资机会或管理不善的风险。

在这个问题上

本期 IEEE 软件为读者提供了对技术债务多方面概念的不同说明。 Erin Lim、Nitin Taksante 和 Carolyn Seaman 进入工业界，检查软件开发人员实际上是如何概念化、感知、体验和管理技术债务的。他们在“平衡法：软件从业者对技术债务的看法”中报告了他们的结果。他们的分析描述了利益相关者短期和长期关注的庞大而复杂的贸易空间，以及他们保持平衡的策略。

Raja Bavani 在“分布式团队、敏捷测试和技术债务”中对两位敏捷专家 Johanna Rothman 和 Lisa Crispin 的采访补充了这一观点。然后，他继续提供自己的技术债务分类及其与测试的关系。

Bill Curtis、Jay Sappidi 和 Alexandra Szynkarski 探讨了使用真实数据检测技术债务的估计框架的可行性。他们使用 CAST Software 开发的代码分析工具包，根据结构质量数据识别大型系统中的技术债务，并在“估计应用程序技术债务的本金”中为其定价。

作为替代方案，Jean-Louis Letouzey 和 Michel Ilkiewicz 描述了“使用 SQALE 方法管理技术债务”。 SQALE 方法基于对应用程序源代码的分析，使用 ISO 系统和软件质量标准（可测试性、可维护性、可移植性等）定义的质量属性指标来缩小关注点。

我们已经超越了金融债务的比喻吗？它仍然有效吗？我们滥用它吗？ Israel Gat 和 Christof Ebert 在一篇观点/对立文章中就这个话题存在分歧。

我们希望通过将其限制在真正的债务上来保持这个债务隐喻的有用性——即过去对软件的决策对其未来产生负面影响的无形结果——并且不将这个概念扩展到任何有成本的事物。从实践的角度来看，我们希望看到更多的工具和方法来识别和管理债务，涵盖更多的领域要素。从理论的角度来看，我们将看到模型的出现，很可能植根于金融理论，例如 NPV，在更广泛的软件进化或软件改进的背景下，可以对这种债务形式进行更好的测量和推理。

Paper3: 10 Years of Technical Debt Research and Practice: Past, Present, and Future

交付越来越复杂 依赖软件的系统需要更好的方法来管理短期权宜之计的长期影响。作为理解和交流此类问题的一种方式，技术债务 (TD) 隐喻已经获得了极大的关注。在 Ward Cunningham 于 1992 年创造该术语近 25 年之后，在第一版 TechDebt 研讨会/会议系列之后 10 多年，我们简要回顾了 TD 的过去、现在和未来。

TD’s Past: Origins and First Research

TD 是软件工程中一个流行的比喻。 Cunningham 介绍它是为了向他的经理解释持续重构的必要性：在迭代而不是瀑布模型中工作可以提高项目速度，就像借钱一样。项目不是花时间首先理解问题，而是在部分理解的情况下立即开始编程。这样，可以更快地交付工作代码，并且用户可以提供反馈以更好地满足他们的需求。但是，与任何债务一样，如果您不断承担更多债务，则必须定期偿还部分本金。否则，项目可能会因兴趣而瘫痪。在软件工程中，可以达到这一点，例如，当新功能和维护的成本超过预算时：项目进入破产状态。

TD兴趣可以采取多种形式。最著名的是较低的可维护性：维护成本高于其他情况。但是，TD 兴趣会影响其他内部和外部质量，例如性能、可操作性（例如，增加成本）和可用性（例如，导致用户避免使用产品或花费更多时间完成任务）。所有这些都会导致项目预算紧张且与 TD 管理相关的费用。根据 Cunningham 的说法，偿还 TD 意味着需要重构软件以反映在项目过程中获得的知识：重构应该努力不断地重写软件，“看起来好像我们一直都知道自己在做什么……并且好像这很容易做到。”在这种解释中，TD 包括内部和外部软件质量的缺陷：重构可能导致重新设计用例（例如，因为我们了解用户真正需要什么）和重写行以修复设计和代码级问题（例如，因为我们学习如何实际使用新框架）。

这种最初的理解既缩小了，也扩大了。它仅限于提及内部软件质量的缺陷，而不是坎宁安更全面的观点。 Fowler 和 McConnel 的定义可能是最著名的，他们将 TD 解释为内部质量缺陷，这与 Dagstuhl 研讨会上关于该主题的定义相似。 3 同时，他们扩大了定义，将 TD 的其他原因和形式包括在内：在他们看来，它可以是故意或无意、谨慎或不计后果的。这扩展了 Cunningham 的解释，因为故意的 TD，例如，通过“编写糟糕的代码”走捷径来加速开发，是他明确反对的想法。今天，其含义已进一步扩展为“开发人员不喜欢的任何代码……hacky 代码、新手编写的代码、不考虑软件架构的代码（所谓的大泥球）以及带有静态分析标记的反模式的代码工具。”总而言之，项目总会有一些 TD 是公认的，承担 TD 可能是有用的，有时甚至是必要的，以取得成功（例如，让初创企业达到上市的关键时间）。 TD 的比喻很快被业界接受。连同破窗理论的概念，它为业务和技术人员讨论软件质量铺平了道路。此外，敏捷概念和框架的出现帮助从业者接受管理 TD，因为它们都在一定程度上强调软件质量和持续重构。

研究人员在 2000 年代初开始研究 TD。直到 2010 年，仅发表了几篇文章，而从 2010 年到 2015 年，出现了第一个更大的研究，这有助于将 TD 概念化。 5,6 TD 已分类。 7 然而，只有某些类型的 TD 得到了彻底调查，而其他类型的 TD 则需要更深入的探索。代码中的 TD（也称为代码债务）是迄今为止研究最多的方面。除了调查和案例研究之外，还有大量关于挖掘软件存储库的工作调查了推迟重构特定问题（例如，代码异味和反模式）的影响。 TD的财务方面也进行了审查。 2 然而，许多人并没有受到同样的关注，至少从 TD 的角度来看是这样。研究产生了用于识别 TD 的商业工具，这些工具被业界采用，从而有助于传播这一概念。流行的工具，如 SonarQube，开发了插件来根据代码气味和规则违规来估计 TD 主体。不利的一面是，他们表现出的印象是 TD 只包含低级代码缺陷，仅此而已。

TD’s Present: Better Understanding, the First Evidence, and New Practices

在 2010 年第一次 TD 研讨会之后，有关该主题的出版物开始成倍增加，尤其是在过去五年中。 2016 年，来自世界各地的研究人员和专家从业者（例如西门子和谷歌）参加了 Dagstuhl 研讨会，目的是了解最新技术，阐明 TD 概念，并为未来研究编制路线图.此外，还编制了一些系统的文献综述，并对从业者进行了几次调查，揭示了各国的实践。一个关键结果是洞察 TD 对软件开发的（代价高昂的）影响：平均而言，估计有 30% 的开发资源因为 TD 而被浪费，峰值为 80%，导致项目危机并阻碍努力实现新的顾客。此外，TD似乎对开发社区的社会结构和开发人员的士气产生了影响，开发人员经常将其称为“涉水”。

研究人员和从业者专注于几个主题，从测量代码库中的 TD（例如，研究几个 TD 索引）到提高软件组织过程中的意识。研究表明，在组织中建立 TD 意识对于建立有效的识别和管理工具和流程至关重要。最近的趋势是调查开发人员自行承认或在代码中标记的债务项目。正在进行的研究还侧重于如何增强软件流程，研究团队如何与 TD 合作并引入跟踪和管理流程。软件公司在管理 TD 方面还不成熟，大多使用非系统方法和一些工具来识别低级代码债务。一个关键问题是，大部分工具都专注于检测代码和低级设计和架构中的 TD，而几乎没有支持检测其他类型的债务。尽管有用于检测架构问题的工具，但它们很复杂，并且大多数都没有提供明确的“债务”指示，尤其是与他们能够找到的问题相关的兴趣。此外，目前的工具缺乏准确性（它们产生许多误报）、完整性（它们没有涵盖许多重要问题）和精细化（它们在实践中不可用）。

鉴于衡量 TD 的艰巨（如果不是不可能）任务，有必要估计本金和利息以在实践中优先考虑 TD。事实上，TD 在短期内可能是有益的，但它的避免或删除通常会优先考虑功能开发，这会导致它在某些情况下具有粘性和毒性（即，它以传染性方式传播和增长））。了解如何估计当前和未来的 TD 本金和利息，以及与组织的路线图的关系，是情境化和做出明智决策的关键。此外，TD 需要与公司的业务建立联系，因为它应该根据其对产品价值的影响进行优先排序。不同的作者提出了优先去除 TD 和开发新功能的方法。

TD’s Future: New Perspectives and Well-Known Open Issues

TD 研究在过去 10 年中缓慢发展。未来十年的重大挑战是什么？本期特刊的文章提供了一个提示：针对众所周知的问题提出了新颖的实用解决方案，并确定了需要填补的空白。一项研究分析了 TD 在存在不确定性的情况下尤其具有挑战性，需要采用协作方法来管理它。对从业者的两项调查总结了特定领域（敏捷项目和游戏开发）中的陷阱和解决方案。其中之一提供了有关障碍、决策因素、支持实践和行动图如何帮助实施预防措施、监控技术和 TD 还款流程的见解。第二个分析了游戏行业如何积累 TD 并将其与其他行业进行比较。一篇文章着眼于通过概念化原因、影响、支付实践和支付避免原因来促进 TD 优先排序和沟通，并为技术和非技术角色提供优先模式。

另一项研究描述了数据科学背景下的挑战，该研究总结了在多个行业研究项目中获得的数据驱动的 TD 管理经验。通过测量代码中的架构气味，可以使用数据来识别（架构）TD：其中一项研究调查了从业者如何感知架构气味，他们与哪些维护和演变问题相关联，他们如何引入它们，以及他们如何处理它们实践和工具的条款。最后，特刊包含一项研究报告，该研究报告了用程序语言处理 TD，借鉴了 GO 的分析和经验，并倡导改进技术以识别该语言和其他语言的债务。

根据过去几年的出版物，我们可以期待看到更多研究 TD 对内部质量（例如故障性、可靠性和代码可维护性）的影响的工作，可能还会增加对非面向对象语言的支持。但是，从实践的角度来看，目前对内部质量的关注过于局限：在争论偿还TD时，利息应该不仅包括可维护性，还包括其他形式，如运营费用、机会成本、安全性、用户体验问题和产品价值。 .例如，最近的研究强调了 TD 如何损害开发人员的士气（和生产力）。在 2021 年 TechDebt 会议上突出的另一个关键品质是 TD 对安全性的影响。这种关系需要进一步研究。

自动识别 TD 项目不应该是唯一的重点：从业者也受益于通过指标间接检测 TD 的支持，他们需要能够将这些项目追溯到代码中的实际债务。在许多情况下，根本原因分析很可能仍然是一个手动过程。 TD 指标可能是一个缓慢但连续地花费更长时间或消耗更多内存的批处理作业（可能是因为内存泄漏或数据量不断增长）。这可能会在很长一段时间内被忽视，直到系统崩溃，从而导致需要紧急修补程序（通常是快速而肮脏的解决方案）的事件，这再次增加了 TD。及早发现这些指标很重要。

研究人员应考虑 TD 的其他方面，例如经济和长期影响以及可能推迟取消债务的原因。为此，指标和“气味”不仅应考虑代码库，还应包括新的数据源，例如项目信息、文档和版本控制工具。同样，组织结构和社会背景等方面可能为如何避免和管理 TD 提供有价值的见解。此外，我们需要将研究范围扩大到更高级别的债务，例如架构级别的 TD，尽管它被认为是更昂贵的类型之一，但它经常被忽视。 8,14 研究人员在几篇文章中探讨了架构级 TD，以更好地了解它是什么以及如何管理它。但是，解决方案仍处于初步阶段。

其他类型较少理解和未充分研究的高级 TD 是需求和域级债务。 15 需求债务通常被定义为已知需求和应用程序之间的差距（例如，故意不完整地实施需求以满足最后期限，意图在以后完成其余工作）。域债务表示应用程序和域之间的差异，开发团队可能不知道。这通常类似于需求债务，但可以被视为不完整、不正确和未识别的需求和领域模型，而不是文档化规定和实现的错位。

例如，用户的工作方式可能与预期不同，或者对域的假设可能不正确（例如，日历约会始终是单个事件）。因此，用户可能缺乏对重要工作流程步骤的支持，或者数据模型可能难以适应并且与域规则不匹配（例如，时间表示为协调世界时偏移，这不利于约会系列）。如果在没有领域知识的情况下检查软件可能看起来很完美：代码可能是高质量的并且符合所有文档。但是，用户可能会受到影响，并且系统可能难以或不可能扩展到新的需求（例如，启用约会系列需要根据时区信息重新设计数据模型）。 TD 项目不局限于可维护性，而是扩展到例如可操作性、可用性和业务敏捷性。这些类型的高级债务很难管理，因为通常需要领域知识才能发现它们，而且它们基于问题空间而不是解决方案空间。这通常使它们在本金和利息方面具有交叉性和昂贵性，因为它们涉及许多利益相关者进行分析和修复。

要解决的最重要的主题之一是如何估计本金和利息以及优先考虑 TD。毕竟，这方面研究的全部目的是了解什么时候应该使用TD，什么时候应该保留，什么时候应该避免或偿还。这个过程可能不会完全自动化，因为通常需要上下文知识。但是，团队将受益于使他们能够系统地评估 TD 并做出明智决策的方法。尽管已经提出了一些方法，但仍需要采取更全面的支持措施。例如，其他类型的债务，如社会和流程债务，已被证明会产生大量的 TD。深入研究 TD 的（经济）影响非常重要。只有有了明确的证据和广泛的实践经验，我们才能最终说服利益相关者，在发展系统时需要考虑 TD。研究人员和业界需要共同努力收集更多证据。

新技术不断被引入，不断发展的软件行业不断采用它们，往往不考虑它们的优缺点，积累的 TD 比预期的要多。示例包括云原生技术，例如微服务和微前端。在采用它们时，公司应考虑在急于重新开发系统时将产生的 TD。存在部分缓解此问题的解决方案，但需要从 TD 的角度对其进行彻底调查。例如，持续集成/持续部署和基础设施即代码可能使公司能够简化其系统的配置和管理。由于快速的配置补丁，这可能有助于减少 TD - 或者如果天真地完成它可能会增加它。另一个例子是围绕机器学习和人工智能的持续炒作。公司仍然不了解控制此类应用程序的质量和 TD 的方法。

未来工作的另一个领域围绕流程支持展开。由于敏捷框架和 DevOps 正在兴起，因此为如何将 TD 管理和缓解策略集成到开发方法中提供指导非常重要。例如，敏捷流程提供了采用良好 TD 管理的机会（例如，通过 Scrum 工具，如回顾、完成的定义和持续重构）。这在 DevOps 中得到了更多的强调，因为业务、开发和运营变得集成，并且系统的用户反馈受到了很大的压力。但是，开发人员可能会发现自己处于一个功能工厂中，在该工厂中，开发人员非常关注开发新功能，而对 TD 几乎没有意识和管理。

总之，我们分析了 TD 管理的过去、现在和未来。自第一届 TechDebt 研讨会以来，已经有 10 年的研究和实践，TD 已经从多个角度被发现、辩论和分析。关于它的好坏影响的证据已经出现，并且已经提出了管理它的初步方法，但需要更多的研究和见解。我们认为，将 TD 管理从青春期带到成年期还需要几年的时间。

Paper4：Technical and Nontechnical Prioritization Schema for Technical Debt: Voice of TD- Experienced Practitioners

技术债务 (TD) 可以在软件开发的任何阶段注入，在其他阶段蔓延并导致各种问题。本文提出了一个模型，用于概念化 TD 原因、影响、支付实践和避免支付的原因，以及技术和非技术角色的优先级架构。

在过去十年中，技术债务 (TD) 研究从隐喻发展到特定的工程实践和用于识别、监控和补救问题的工具。这一进步大部分与最明显的软件工件有关：源代码。然而，今天我们知道 TD 可以注入到几乎任何工件和软件开发的任何阶段，从而产生不同的风格——TD 类型——例如代码、架构、设计、文档、测试、流程和人员债务。这是可以理解的，因为软件开发是从业者之间的协作努力，致力于解决和决定许多问题，这些问题可能更接近源代码工件，因此更技术性或更远离它，即非技术性。所有决策都会影响产品的创建，因此可能会导致 TD 的创建。

技术和非技术观点的重要性虽然显而易见，但在推理 TD 时仍未完全理解。在某种程度上，很容易想象技术和非技术优先级不一致导致次优决策的情况，从而导致注入新的 TD。毕竟，隐喻的引入是出于向非技术利益相关者传达重要技术概念（例如重构）的新兴需求。 TD 现象的一个重要特征，根植于其性质，是负面影响表现的内在时间延迟。因此，最有价值的经验教训来自积极参与管理 TD 的从业者。

在本文中，我们关注 TD 经验丰富的从业者以及他们如何概念化关键 TD 结构。我们使用了一系列调查（参见“方法学方法”）来收集行业专家的反馈。本文最显着的特点包括：

• 分析了 168 名具有 TD 管理经验的从业人员的回复，其中 74% 具有技术角色，26% 是非技术角色

• 介绍了用于概念化 TD 原因、影响和支付实践的模型，以及避免付款的原因，以及技术和非技术角色的优先模式以及提取和解释的 25 个高优先级因素

• 分析两个观点之间的一致性；数据表明，TD 原因和支付实践的技术和非技术观点高度一致，而关于 TD 影响和避免原因的观点则明显不一致。

本文中的发现不同于并补充了大多数 TD 管理方法，这些方法侧重于识别、优先排序、监控和缓解受 TD 感染的软件工件。我们提供了一个概念模型，该模型考虑了背景因素，并以重要因素的优先列表形式呈现。从业者可以利用图形显示的结果和信息（图 1）来应对围绕 TD 管理过程的背景因素。

图 1. TD 注入的概念模型以及在软件开发期间如何对其进行操作。技术和非技术视角采用前五个 TD 原因、影响、支付做法和避免支付的原因进行建模。此外，为每个 TD 结构计算秩偏重叠 (RBO) 统计数据。

Ubiquitous Awareness of TD

Ward Cunningham 在 1990 年代通过在内部软件质量方面和财务债务之间进行类比引入了 TD 隐喻。虽然这个比喻很容易理解，但潜在的现象仍然是难以捉摸的、多方面的和普遍的。多年来，内部软件质量的不同方面以各种名称进行了研究：软件维护、演化、老化、衰减、再造、可持续性等。后来，很明显，所有这些方面无可否认，最重要的成就是行业从业者对 TD 认识的提高。在我们的研究中，我们观察到十分之七的从业者了解 TD 及其后果。尽管他们中的一些人没有使用复杂的工具和技术进行 TD 管理，但他们的意识是令人鼓舞的。

Conceptualizing TD Elusiveness and the InsighTD Survey

TD 的本质是难以捉摸的，而且往往是不言而喻的，这不仅是对研究的挑战，也是对行业的挑战。因此，我们使用了一项调查，该调查使用了软件开发中涉及的各种角色都可以理解的一些结构：TD 原因、影响、支付惯例和支付规避。导致 TD 注入的先决条件被建模为原因。例如，一些经常被引用的原因与缺乏时间和资源有关。请注意，原因代表利益相关者对可能导致对 TD 做出有偏见的决策的触发因素的理解。 TD的表现通常被称为效应或症状。对影响的认知有助于利益相关者对注入债务的后果可能发生的潜在问题进行推理。这种推理决定了债务清除的进一步行动。

尽管很难量化负面影响的影响，但一些研究提供了估计值，例如，每行 TD 源代码 2 美元到 20 美元之间，或者 25% 的开发工作用于 TD 引起的问题。一旦 TD 影响变得可见，就需要决定是否支付（即补救）影响或接受它们并避免任何纠正措施。

方法论

这项研究是 InsighTD (http://www.td-survey.com) 的一部分，这是一项从不同角度调查技术债务 (TD) 的全球倡议。使用一系列调查来收集数据，而调查设计 (https://bit.ly/2SCOM9S) 使参与者能够报告 TD 结构的多个实例、TD 管理相关信息和人口统计详细信息。参与者选择遵循便利抽样方法，S1 得到 653 个响应。该研究依赖于 168 名参与者的回答，其中 124 人是技术人员，44 人是非技术利益相关者。参与者报告说他们在软件开发和 TD 管理方面经验丰富（图 S1）。

使用定性和定量研究方法对数据进行分析。定性编码用于分析开放性问题，即识别 TD 结构。 S2 描述性统计主要用于表征人口统计学（封闭式问题）和确定的 TD 结构。排名偏向重叠 (RBO) 用于比较技术和非技术列表（RBO 分析可在 https://bit.ly/3qjEZSK 访问）。

为了传达内部有效性，每个研究团队都遵循一个共同的分析程序，包括迭代、审查和共识决策。此外，每个团队都改进了基于先前复制的通用代码模式。通过收集来自不同国家、工作环境和角色的行业从业者的数据来解决外部有效性问题。我们承认，技术和非技术响应的数量不平衡可能会挑战研究结果的普遍性。尽管如此，由于 RBO 对频率变化具有弹性，并且由于目标人群固有的不平衡，因此该样本被视为适合本研究。

图 S1。 (a) 受访者对 TD 的熟悉程度。 (b) 管理 TD 的人员的专业水平。 (c) 管理 TD 的称职、精通和专家从业者的人口统计数据。 KLOC：千行代码； MLOC：百万行代码。

Prioritization Schema for TD Constructs

有许多因素会导致对 TD 注入有利的情况，以及许多影响对注入债务进行补救或接受的决定的问题。有些方面是独特而具体的，而其他方面则可能出现在不同的项目环境中。通过对 TD 结构进行优先级排序，我们提取了更多代表关于 TD 的可概括知识的常见因素。此外，比较技术和非技术优先级模式可以让我们深入了解这些群体对已识别因素的看法的一致性水平。因此，预计更好的对齐会导致更好的沟通和更少的摩擦。

图 1 描述了注入和处理 TD 的过程。在注入之前，潜在原因可能会造成导致 TD 的情况。理想情况下，可以在注入债务之前识别原因。这需要所有相关从业者的积极监督。从图 1 中，从业人员可以从技术或非技术角度了解最重要的原因。优先级表明哪些原因对于 TD 注入更为严重。

一旦出现 TD，就可以识别出许多症状。请注意，症状和影响可能被视为 TD 的指征。建议特别注意具有更高优先级的效果。根据有 TD 经验的从业者的说法，优先级越高的效果表明患 TD 的可能性越大。效果优先级架构可用于在识别任何特定 TD 问题之前评估情况。在某个时候，会做出补救 TD 问题的决定。这一决定特别有趣，因为它背后的过程揭示了组织管理 TD 的成熟度。例如，在某些公司中，会使用一种成本效益分析形式来争论决策，而在其他公司中，不会明确做出选择；即，隐含地，TD 在没有明确推理的情况下被接受。

与 TD 打交道的从业者可能会在不认为这是一个问题的业务经理和期望采取行动的同事之间处于一个令人羡慕的位置。 TD 做法和避免付款原因的优先级模式（图 1）可以通过建议最有效的 TD 付款做法和提供最重要的避免原因来提供帮助。特别是，避免付款原因列表可以成为客观地准备和辩论 TD 付款决定的有力工具。例如，如果就处理 TD 达成共识，从业者应提前解决所有主要原因，采取措施消除它们。这可以包括投入资金、时间和资源以及改变短期目标。这样一来，处理TD的成功率就会提高。

Alignment and Misalignment of Technical and Nontechnical Perspectives

使用秩偏重叠 (RBO) 方法评估技术和非技术优先级模式的一致性。 9 RBO 结果显示原因和支付实践模式是一致的 (RBO >= 0.8)，而效果和支付避免原因模式不同 (RBO <= 0.8)，因此是不一致的。为了计算相似度，RBO 使用按频率排列的已识别因素列表。前五个因素是技术和非技术列表中的一个，因此在两者中都标有一个点。此外，非技术列表中的其余四个项目具有相同的优先级（两个），因为它们在相应组中的所有引用中具有相同的百分比（10%）。此外，指标有助于比较优先事项；例如，非技术列表上的设计重构比技术列表上的设计重构具有更高的优先级，并且在非技术列表上用绿色三角形标记，在技术列表上用红色三角形标记。

Alignment of Perspectives on TD Causes and Payment Practices

技术和非技术从业者概念化 TD 原因和关于支付实践，代码重构从这两个角度来看都具有最高优先级。看到非技术参与者理解代码重构的重要性令人鼓舞。根据我们的研究，我们推测这种做法不再难以解释和与非技术从业者交流。十年前，重构是一种典型的技术实践，很难向非技术利益相关者描述。

Misalignment of Technical and Nontechnical Perspectives on TD Effects and Payment Avoidance

两组之间对效果和未付款原因的看法远没有那么一致。然而，从中可以观察到有趣的共性。首先，没有特定于一个观点的 TD 效应和未付款原因的显着独特实例。这表明不同的角色对影响的重要性和避免付款的原因有特定的观点。其次，避免TD付款的原因在两组中具有最高优先级，可能与组织问题有关，因此属于管理领域。技术从业者似乎明白，不付款的原因和原因在本质上也是非技术性的。

确定的优先级模式通常包含相同的因素，但这些因素在技术和非技术环境中不一定具有同义词。例如，在非技术环境中，缺乏技术知识可能表明需要熟练的需求管理工具的从业者，而在技术环境中，则需要熟练的单元测试人员。另一方面，代码重构的含义是相同的，与上下文无关。在第一种情况下，一个因素是相对于特定于组的伪影来解释的，因此需要不同的处理。在第二个中，两个组中的因子解释保持不变，因为该因子与同一个工件相关联。突出解释差异有助于更好地沟通和推理 TD 结构。

在未来的几年里，我们需要更多地研究减轻软件开发过程压力的方法，以减轻 TD 的负面影响。需要在组织和管理层面理解这些方法的重要性。 InsightTD 项目致力于调查 TD 现象；感兴趣的读者可以在 http://www.td-survey.com 找到信息，除了研究路线图和出版物，还有加入指南。

技术债务研究综述X4相关推荐

基于机器学习的软件缺陷预测技术的研究综述
本文基于马樱博士<基于机器学习的软件缺陷预测技术研究>归纳总结而成,不具备论文作用,仅为学校交流中文摘要自过去几十年来,软件规模不断扩大,计算机程序设计变得更加复杂,软件规模显著增长, ...
读“基于深度学习的图像识别技术研究综述”有感
"基于深度学习的图像识别技术研究综述"总结现在流行的图像识别技术都是基于深度学习的算法,经过前辈们的探索改进,图像识别技术经历很多阶段,现如今图像识别技术已经广泛的应用于生活的方 ...
【技术综述】人脸颜值研究综述
文章首发于微信公众号<有三学AI> [技术综述]人脸颜值研究综述今天带来一篇人脸识别中的颜值打分技术,所谓"颜值",基于什么标准来评判高低呢?既然是个"数值 ...
深度学习在机器视觉应用领域的最新研究综述（物联网技术应用大作业）
摘要:机器视觉是人工智能正在快速发展的一个分支.简单说来,机器视觉就是用机器代替人眼来做测量和判断.机器视觉系统是通过机器视觉产品(即图像摄取装置,分CMOS和CCD两种)将被摄取目标转换成图像信号, ...
数字水印技术研究综述
数字水印技术研究综述引言信息媒体的数字化为信息的存取提供了极大的便利性,同时也显著提高了信息表达的效率和准确性.特别是随着计算机网络通讯技术的发展,数据的交换和传输变成了一个相对简单的过程,人们借 ...
论文简读《视听觉深度伪造检测技术研究综述》
<视听觉深度伪造检测技术研究综述> 概述: 深度学习被广泛的应用于各个领域,自然语言处理.计算机视觉.无人驾驶等,推动了人工智能的发展.但在带来好处的同时,也对信息安全方面也有一定 ...
区块链技术研究综述：原理、进展与应用
来源:区块链技术研究综述:原理.进展与应用期刊:通信学报. #blockchain 相当于对区块链先进行一个系统的了解吧区块链的层次化技术结构. #未解决的问题上述文献虽然归纳得较为 ...
《拜占庭系统技术研究综述_范捷》笔记
<拜占庭系统技术研究综述_范捷>笔记文献信息:清华大学,期刊,2013,范捷 Abstract 分析了目前拜占庭系统的研究现状,并探讨了拜占庭系统的发展趋势 Conclusion 成果涌 ...
uniyu 雷达波束_雷达极化信息获取及极化信号处理技术研究综述
[1] Sinclair G.The transmission and reception of elliptically polarized waves[J].Proceedings of the ...

技术债务研究综述X4

Paper1: Managing Technical Debt

与金融债务的比较

管理你的债务

不同角度的债务成本

总结

Paper2: Technical Debt: From Metaphor to Theory and Practice

组织技术债务状况

处理技术债务

统一理论？

在这个问题上

Paper3: 10 Years of Technical Debt Research and Practice: Past, Present, and Future

TD’s Past: Origins and First Research

TD’s Present: Better Understanding, the First Evidence, and New Practices

TD’s Future: New Perspectives and Well-Known Open Issues

Paper4：Technical and Nontechnical Prioritization Schema for Technical Debt: Voice of TD- Experienced Practitioners

Ubiquitous Awareness of TD

Conceptualizing TD Elusiveness and the InsighTD Survey

方法论

Prioritization Schema for TD Constructs

Alignment and Misalignment of Technical and Nontechnical Perspectives

Alignment of Perspectives on TD Causes and Payment Practices

Misalignment of Technical and Nontechnical Perspectives on TD Effects and Payment Avoidance

技术债务研究综述X4相关推荐

最新文章

热门文章