如何评估、管理和避免技术债务

如果技术债务听起来像是从金融手册中摘录的，那是因为该术语与金融有关。 然而，从真正意义上来说，技术债务与编程有关。 它的想法是，在软件项目的开发过程中，某些必要的步骤被跳过，或者只是为了赶上最后期限而完全放弃。

为了开发完美的应用程序或软件，开发人员通常时间紧迫——就像任何随机执行任意任务的人一样。 因此，在交付具有完美代码的完美产品和最大化时间之间进行某种权衡通常是有意义的。

那么问题是：这些权衡是否有限制？ 这种权衡是否会导致固有的危害？ 最后，从长远来看，开发商真的会更好吗？ 在这篇关于技术债务的文章中，我将尝试回答所有这些问题。

什么是技术债？

在定义技术债务时，我们必须首先提及创造该术语的人：Ward Cunningham。 根据 Cunningham 的说法，技术债务是指在编写代码时必须进行的额外开发工作，以弥补在短时间内编程所产生的缺陷。

为了使它更形象化，想象一下你的任务是清理一个凌乱的房间，而你上课要迟到了。 为了确保您执行指令并准时上课，您会进行快速清洁，将沙发底下的大部分杂物清扫干净。 这样做的后果是您最终将不得不花时间整理混乱。 对于软件开发，当您跳过必要的步骤并遵循更简单的路线时，使用“不那么干净”的代码，将来清理代码会变得更加困难。 软件项目多米诺骨牌中会遇到多个阶段，您忽略现有问题的时间越长，解决问题所需的时间就越长。

技术债务的类型

技术债务有不同的类型，包括：

计划的技术债务

这发生在组织故意决定承担技术债务的情况下。 如前所述，这通常是为了超越规定的最后期限并达到特定目标。 在参与计划中的技术债务时，组织需要清楚他们愿意放弃什么，以及他们不能放弃什么。 你必须保持准确的记录，记住你最终必须返回并纠正你一开始跳过的错误。

无意的技术债务

这种类型的技术债务与第一种直接相反。 当组织没有预见或计划技术债务时，就会出现这种情况。 造成这种情况的原因通常是组织中各个单位之间的沟通中断，或者单位之间糟糕的工作实践。

不可避免的技术债务

这是组织方面任何行动都无法阻止的技术债务。 例如，随着技术的快速变化，过去编写的一些代码将达不到当前预计的标准是有道理的。

此外，当在编写代码时请求更改时，可能会出现这种技术债务。 如果在设计软件的中途引入了某些更改，它可能会扰乱动态，使旧代码过时或不必要。

技术债务的原因

上面已经讨论了技术债务的一些原因，但我只是将它们一个接一个地挑选出来以使它们更清楚。

急速

技术债务最常见的原因是仓促。 开发人员通常有严格的截止日期，其中一些包括启动某些软件的截止日期。 在这种情况下，开发人员可能会在此过程中产生技术债务，这通常是可以理解的（并且是预期的）。 这种类型的技术债务通常是故意的，可能会导致代码中出现错误或出现意大利面条式代码等问题。

疏忽/错误

有时，程序员只是编写糟糕的代码，最终导致技术债务。 不管不良代码是否由于编码人员的错误而存在，事实是错误会导致技术债务，并且由于它们不可扩展，因此最终必须进行修复。

缺乏对影响的认识

有时技术债务的出现是因为编码人员没有意识到或承认从长远来看技术债务是多么有害。 这可能源于对编程过程中走捷径的有害影响的合理无知，也可能是故意无视后果。

意图

编码人员或组织的故意行为可能会故意产生技术债务。

缺乏模块化

这主要是因为一个代码可以同时服务于不同的业务逻辑。 这种情况使处理软件变得更加困难。 对于开发人员编写的每个代码，他们遇到模块化挑战的机会就越大。

技术债务评估

永远不应该手动计算技术债务，因为那将是相当艰巨的。 这意味着必须手动输入代码来确定当前问题和未来可能出现的问题。 除了手动过程浪费时间之外，代码有可能在手动过程结束时改变形式。

执行评估的一种方法是使用一些支持它的工具执行静态分析。 一些可以使用的工具包括 Coverity、SonarQube、Check Style 和 Closure Compiler。

一般来说，有两种计算技术债务的方法。 在第一种方法中，可以通过计算代码比率之后的技术债务比率来获得。 在这里，开发应用程序所需的初始估计或总时间将用于确定修复技术债务所需的时间。

在第二种方法中，您可以直接使用 SonarQube 等各种工具给出的估计值。 这将与技术债务清单及其参考代码相结合。 通过这些工具，您可以准确估计修复它所需的时间长度。

评估技术债务将使您了解修复技术债务需要多少天。 债务越多，解决它的时间就越长。

解决技术债务

如果发生了技术债务而您不知所措怎么办？ 您可以采取某些步骤来管理技术债务。

首先，您应该承认存在技术债务并将其传达给您的团队。 在沟通中，你应该清楚发生了什么以及需要做什么来纠正它。 您应该确保尽早清楚地传达处理技术债务的必要性。

在通知您的团队技术债务后，您可以采取三种方法。 在第一种方法中，您可以决定继续使用系统。 在这种情况下，应用程序将按原样使用。

或者，您可以决定重构应用程序。 重构的目的是降低应用程序的复杂性以及清理应用程序的结构。 通过重构，软件的行为不会改变； 唯一受影响的部分是内部结构。

最后，如果上面讨论的两个选项都不起作用，您将不得不完全替换代码。 这样做的一个问题是它可能导致新的技术债务，但从长远来看，这可能是一个更好的权衡。

避免未来的技术债务

当然，避免技术债务绝对比在它们出现时尝试修复它们更明智，这是不言而喻的。 除了可以节省您的时间和压力之外，它还可以确保不存在从一开始就存在技术债务的残余后果。

可以说，技术债务本身并不坏。 它们通常是有问题的，因为它们是必须偿还的债务，而人类不是地球上最负责任的物种。 始终选择较弱的选项通常会削弱软件的强度，并使以后改进功能变得更加困难。 总之，避免技术债务是任何人的最佳选择。

那么，如何防止出现技术债务：

创建项目待办事项

这里的想法是让每个人都了解这个过程，并让他们跟上正在执行的任何任务的要求。 创建积压工作让每个人都可以看到未完成的任务，以及实现这些任务的路径。

质量优先于速度

如果你自己是一名程序员，你必须学会​​优先考虑高质量的工作而不是大量的工作。 确保您的代码是干净的，并且您的应用程序或其他软件开发得完美无缺。 要明白，走捷径的诱惑是不值得的，因为最终，你仍然必须完成你放弃的任务。

如果你领导一个团队，你必须将这些相同的价值观传达给团队成员。 应该教导成员创建以结果为导向的解决方案并避免走捷径。

创建意识

一般来说，深入了解什么是技术债务以及如何避免技术债务可能有助于从一开始就防止它们出现。 当您用必要的知识武装您的开发人员时，他们将更好地避免技术债务带来的陷阱。

介绍良好的编码实践

一些编码实践使您更有可能陷入技术债务。 因此，避免紧耦合、采用抽象和重构会很好。

引进最新技术

定期更新技术可能是防止技术债务的绝佳手段。 在更新中，你必须确保使用的是最新的框架、数据库和应用软件。

结论

在绝大多数情况下，只要您继续开发程序和编写代码，技术债务是不可避免的。 但是，如果按照上面列出的步骤进行操作，它们发生的机会就会大大降低。 此外，即使出现技术债务，也不会失去所有希望。 保持冷静，自信，采取相应的行动。