跳到主要内容

什么是技术债务?示例、预防和最佳实践

什么是技术债务?示例、预防和最佳实践

技术债务

大多数软件开发人员都熟悉 技术债务,但对于编程专业以外的人来说情况就不那么真实了。

理解这一概念很重要,因为它适用于短期决策可能产生长期影响的广泛场景。以下是您需要了解的技术债务示例和最佳实践。

什么是技术债务?

技术债务是将快速交付置于最佳代码质量之上的结果。当软件开发团队选择快速修复而不是长期解决方案时,就会产生技术债务。

债务的比喻很恰当。当一个人承担债务时,通常是因为短期内需要财务资源。然而,当债务必须偿还时,这会产生额外的成本。

技术债务的工作方式类似,用权宜之计来换取后续的额外工作。

如果最终不重新审查和修复代码,它就会成为一个问题,就像不偿还贷款就会产生利息和罚款一样。

技术债务不一定是个问题。但是,如果产品优化不佳或代码功能失调,它就可能成为问题。

技术债务的例子

技术债务的一个典型例子是 2000 年(Y2K)问题。

1960 世纪 1970 年代和 73 年代,许多软件开发人员选择将日期存储为两位数,以节省宝贵的内存。因此,使用“1973”而不是“XNUMX”。

即使内存价格下降,这种做法仍持续了多年。许多程序已嵌入运营业务,并且使用时间远远超出预期。

随着 2000 年的临近,成千上万的企业和政府机构意识到日期计算将大规模失败。这导致了一场疯狂的清理工作,估计有 成本$ 100十亿.

但技术债务并不局限于软件。例如,网络安全的最佳实践是将文件权限授予组织内的角色,而不是个人。

假设一名行政助理获得临时访问敏感文件的批准,而他们通常无权查看这些文件。如果 IT 部门批准了这一例外,但后来未能撤销,则意味着该部门授予了对敏感文件的永久访问权限。该帐户最终可能会受到攻击并出现漏洞。

 

技术债务的危害是什么?

如果短期修复能够快速重构,并且开发人员知道如何处理技术债务,那么几乎没有什么坏处。甚至可能还有好处,因为它可以让企业快速响应机会或问题。

当债务层层叠加时,风险就会增大。

快速修复可能记录不全,甚至根本没有记录。当执行快速修复的人离开时,公司可能没有人知道代码应该如何工作,甚至不知道快速修复的存在。

增强或更改可能会产生意想不到的冲突,导致程序失败或运行缓慢。由于组织担心更改会破坏应用程序而不敢进行改进,因此创新速度会减慢。

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

技术债务的两大类别是 故意 无意.

开发者培训公司首席执行官史蒂夫·麦康奈尔 建筑,定义 有意技术 债务是人们有意识地、有策略地承担的。

他定义 无意的技术 债务是“工作做得不好造成的非战略性结果”。

2014 年,一组学者开发了一种 分类 包括 13 种不同类型的技术债务:

  • 建筑债务
  • 建立债务
  • 代码债务
  • 缺陷债务
  • 设计债务
  • 文件债务
  • 基础设施债务
  • 人民债务
  • 流程债务
  • 要求债务
  • 偿还债务
  • 测试自动化债务
  • 测试债务

这种分类很有用,因为它涵盖了短期思维可能产生长期问题的所有领域。

技术债务是如何产生的?

以下是某些类型的技术债务可能产生的几种方式。

有意的技术债务

故意造成技术债务是明智之举。应记录并安排重构。

例如:一位区域销售经理需要在截止日期前生成一份其平台无法创建的报告。该经理开始使用开源报告编写器来满足截止日期。这就是技术债务。

但是,如果开发团队花费资源删除开源报告编写器并修改主报告系统,那就是故意的技术债务。

无意的技术债务

无意的技术债务是指出于权宜之计而没有重构代码的计划而进行的更改。

也可能是由于缺乏知识或未遵循开发标准而导致的设计决策不当。测试领域中无意的技术债务发生在以下情况:

  • 测试套件不完整
  • 测试被截断
  • 为了方便起见,跳过了测试

文件债务

文档债务很常见,当开发人员过于匆忙而没有完整地记录他们的代码时就会发生。

如果某人离开公司时没有留下说明来让大家理解其代码,那么从长远来看,这可能会成为一个问题。文档债务是 Y2K 问题的主要贡献者。

基础设施债务

当应用程序依赖于某些组件(例如数据库和文件系统)时,就会产生基础设施债务。如果这些依赖关系没有记录下来,并且公司迁移到新的基础设施,应用程序可能无法运行。

技术债务的警告信号是什么?

技术债务的警告信号是:

  • 由于开发人员缺乏对代码库的了解,项目陷入停滞
  • 由于复杂性或缺乏文档而难以修复的错误
  • 修复错误会导致新的错误或持续的性能下降

如何管理和预防技术债务

了解如何处理技术债务始于完善的开发实践。在 DevOps 环境中,这包括左移和右移测试。

  • 左移测试 将测试过程提前到开发周期的整个阶段。这样可以在问题进入生产之前预测并解决问题。
  • 右移测试 在应用程序投入生产后寻求反馈。这样,在软件广泛使用之前,可以尽早发现并修复错误。

这些设置可以防止问题变得过于严重。

造成技术债务的变通方法是不可避免的,而且往往是必要的。然而,开发人员必须记录这些变通方法,包括实施黑客攻击的原因以及修复方法的说明。

定期审核现有代码还可以让团队成员审查彼此的工作并发现文档的缺陷或违规行为。

最佳做法是什么?

当组织采用 DevOps 技术时,他们应该明确什么是技术债务,并应用敏捷策略来管理它。这可能包括实施:

  • 右移和左移测试
  • A/B 和金丝雀测试技术可在问题失控之前发现问题

同行代码审查允许新人以全新的视角审视开发人员的工作。开发人员应使用一致且有限的工具和语言,并列出每个阶段必须完成的任务清单。

有效的 DevOps 组织 让开发者可以自由选择如何构建自己的作品。它还提供护栏以确保他们不会失控。

哪些工具可以防止技术债务?

上述做法是一个良好的开端。通过以下方式可以实现其他好处:

  • 运用 自动化测试 每当模块发生变化时,对每个代码更改运行多个调试周期
  • 建立 音码结构 程序,包括强制性文件,以防止变通方法
  • 运用 项目管理工具 使团队能够了解每个人的工作状态
  • 程序员以团队形式工作 让他们能够理解彼此的决定

如今,大多数软件都是用低代码和无代码工具编写的。这些工具都是自文档化的,使用流程图和拖放技术可以直观地呈现逻辑和期望的结果。

通过将这些工具应用于专业软件开发,您可以从自文档功能中受益。开发经理应鼓励团队将低代码/无代码视为提高生产力的方法,而不是将其视为优雅创作的替代品。

常见问题

  • 技术债务是好还是坏?

    技术债务是一把双刃剑:如果故意而为,则是战略性的,如果忽视,则是有害的。

  • 技术债务的 80 20 规则是什么?

    80/20 规则建议关注导致 20% 问题的 80% 技术债务。这种方法平衡了短期进展与长期可持续性,确保解决关键债务问题,同时避免完美主义。

  • 我应该分配多少时间来解决技术债务?

    将 20-30% 的开发时间分配给管理技术债务。这个“债务偿还计划”可以保持代码健康,而不会扼杀创新。根据项目成熟度进行调整:较新的项目可能需要较少的债务,而遗留系统可能需要更多债务。定期的“债务冲刺”可以帮助系统地解决累积的问题。

  • 技术债务的另一个名称是什么?

    设计债务 or 代码债务 是技术债务的替代术语。有人称其为 技术责任 以强调其对资产负债表的影响。 软件熵 在学术界使用,而 代码异味 指潜在技术债务的指标。每个术语都强调了软件开发中累积妥协的不同方面。

选择你的语言