编程中的恶业。什么是技术债务以及如何解决它

技术债务。大多数积极从事其专业工作的程序员都必须处理这个术语。对于许多人来说，提及它甚至会引起头痛，以及每当您在项目中处理技术债务时就会出现身体其他部位的不适。 因此，今天我们将讨论技术债务（TD）：它是什么、它是如何出现的、技术债务有哪些类型以及如何有效地管理它。

什么是技术债务？

不过，首先让我们了解一下术语。技术债务是一种软件工程隐喻，指的是由于忽视软件开发质量而在软件代码或架构中积累的问题，并在未来造成额外的劳动力成本。这是维基百科给出的技术债务的定义。简单地说，技术债务是在开发中应用简化和短期解决方案的结果，这导致后续改进的金钱和时间成本不断增加（当然，除非债务被“偿还”），重写代码或以现有形式维护产品。在普通程序员的世界里，技术债务是一种负面业力，一种消极因素和悲伤的根源，它是对糟糕代码的报应，使用拐杖和“临时”（但实际上不是很好）的解决方案帮助解决短期问题并“赊账”地加快发展，即以牺牲未来日益复杂的问题为代价。在IT行业，技术债务是一个相当严重的问题。根据最近的一项研究，世界各地的公司每年仅花费超过 850 亿美元来修复不良代码。每年总共约有 3000 亿美元花费在与支持过时系统和“不良”软件相关的项目上。这些都是重要的数字。研究人员估计，如果所有处理技术债务及其后果的开发人员的努力重新集中在“正确”的开发上，那么在当前十年中，全球 GDP 将会增加约 3 万亿美元。

出现原因

应该理解的是，技术债务并不总是坏事，就像陷入金融债务可能是积极的，例如，如果您贷款来发展业务（或创办一家初创公司）。就 TD 而言，这对于快速成长的公司来说是可以接受的，这些公司需要快速且频繁地发布新产品或服务，以评估其成功并研究市场需求，或快速占领新的利基市场。但是，与金融债务一样，您需要小心技术债务并知道如何管理它，否则可能会出现严重的问题。软件产品开发过程中积累的技术债务越多，对公司的影响就越大，减慢新版本的发布速度，降低负责“维护”此类债务的普通程序员的士气，并增加成本，最终甚至会毁掉公司。技术债务发生的原因，除了尽快完成产品或以新版本取悦用户的崇高愿望之外，往往是产品管理不善、不切实际的截止日期或资源限制，当然还有编码人员的懒惰加上资质低下以及缺乏对关键发展原则的理解，也往往会助长债务的增长。经常发生的情况是，开发人员本身很清楚技术债务的存在和不断增长，但没有足够的权力来改变它，或者无法向管理层传达有关此类问题的存在以及解决该问题的重要性的信息。

分类

如上所述，技术债务有多种不同的形式，由于定义本身只是一个比喻，不同类型的技术债务可以有不同的分类方式。尤其是被认为是全球技术债务专家之一的Tapad联合创始人兼CTO Dag Liodden，在年度CTO峰会活动的演讲中提出将技术债务分为三大类。

1. 故意的技术债务。

   它出现在开发人员故意选择不是最佳解决方案的情况下，因为实施起来更容易、更快，这反过来又有助于快速向市场发布新产品。

   “有时我们故意承担技术债务以减少开发时间。如果您决定走这条路，不仅要考虑在开发过程中节省的时间，还要考虑以后“还清”此类债务所需的时间。此外，还要确保利益相关者（公司高层管理人员）意识到这样的决定将不可避免地减慢未来其他功能的推出，”Dag Ljodden 说。

   解决此类技术债务的方法

   专家建议仔细记录此类案例，以便在技术债务消失之前返回并纠正它们，使其成为项目结构的组成部分。

2. 意外的或由过时的项目架构产生的技术债务。

   此外，由于创建项目架构阶段的错误和缺陷，技术债务通常会随着时间的推移而出现。随着系统的发展和软件需求的变化，设计错误变得更加明显，添加新功能需要更多的时间和精力。初始项目架构的质量在这里起着重要作用——它应该既简单又实用，这样才更容易适应变化。

   解决此类技术债务的方法

   为了防止此类技术债务累积且不超过临界水平，Dag Llodden 建议在系统处于稳定状态期间定期进行重构 - 大约每两年一次。团队领导和产品经理必须分配时间来“偿还”由于项目的架构和频繁变化的需求而产生的这种技术债务。

3. 随着时间的推移而产生的技术债务。

   专家称这种技术债务是“长期腐烂的”。随着时间的推移，由于不断添加许多更改，组件或系统逐渐变得更加复杂，它会随着时间的推移而累积。如果不同的人在不同的阶段处理系统并且不完全理解原始架构，情况往往会变得更糟。

   解决此类技术债务的方法

   专家表示，这是您应该通过定期重构持续避免的三种技术债务中的唯一一种。理想情况下，开发团队应该花时间彻底了解他们正在开发的系统的架构，即使它最初是由其他人创建的。了解该系统将使您能够逐步改进和纠正错误的代码，而不会让项目陷入“腐烂”的阶段。

技术债务管理解决方案

有效管理技术债务的选择有很多，但所有专家都认为必须这样做，因为技术债务几乎是所有开发中不可或缺的一部分，而那些忽视它的公司总是会在后期面临问题。以下是一些管理开发团队技术债务的有效解决方案和方法。

1. 分配固定百分比的工作时间来处理技术债务。

   关于技术债务的问题是，除非您有目的地这样做，否则永远没有时间消除它（因为总是有更高优先级的任务）。因此，一个好的解决方案是为这些目的分配一定固定百分比的工作时间——大约 20-25%。

   这可以通过不同的方式来完成。

2. 每周 1 天处理技术债务

   Если выделять на работу над устранением ТД всей командой один день в неделю, это How раз будет около 20% от общего рабочего времени. Для некоторых команд такой подход работает просто отлично и, говорят, даже повышает мораль, ведь в этот конкретный день недели вся команда занимается решением проблем, которые достают их все остальное время разработки.

3. Посвящать работе над ТД каждую четвертую задачу

   Такая система подходит тем командам, которые склонны разделять работу над проектом на примерно равномерные по времени и усorям для их выполнения задачи. Если один из каждых четырех тасков посвящать “выплате” ТД, это будет занимать около четверти всего времени разработки. А введение такого подхода в качестве правила позволит убедиться, что codeеры не будут откладывать технический долг “на потом”.

4. Переходящая роль

   Еще одним подходом к проблеме устранения технического долга будет назначать на данную задачу разных членов команды поочередно, чтобы равномерно распределить эту порой далеко не самую приятную работу среди членов коллектива. Количество разработчиков, назначенных заниматься “разгребанием” ТД, может быть разным — для команды из 4-5 человек будет достаточно одного, тогда How коллективы побольше могут назначать двух-трех. Но суть остается прежней — на работу над ТД должно уходить около 20-25% всех ресурсов и человеко-часов.

5. Правило бойскаутов.

   Правило бойскаутов состоит в том, чтобы всегда оставлять туристический лагерь (стоянку для палаток) в лучшем состоянии, чем он был до их прихода, то есть убирать даже тот мусор, который был оставлен не ими. Этот принцип, How выяснor заокеанские codeеры, отлично подходит и для управления техническим долгом. Согласно данному правилу, все члены команды должны заниматься исправлением ТД каждый раз, когда сталкиваются с ним в том or ином виде. Конечно, это правило нужно применять разумно, чтобы время, которое уходит на исправление ТД, не превышало “разумные” 25-30% от общих временных ресурсов.

6. Приоритизация “дорогого” технического долга

   Также эксперты в массе своей рекомендуют не забывать о том, что технический долг может различаться в том числе и по важности. Далеко не каждый тип ТД требует немедленного устранения, поэтому важно работать над классификацией разных видов технического долга и приоритезацией работы с ними соответственно. Проще говоря, прежде всего закрывать надо те долги, которые оказывают прямое влияние на speed разработки продукта, будучи частью его базовой архитектуры. Такие долги являются самыми опасными, потому что ведут к появлению новых долгов, которые могут расти How снежный ком.

Заключение

最后，我想再次强调，软件开发中不可能没有技术债务，因为它们本身就是开发不可或缺的一部分。然而，尽管TD具有技术性质，但它仍然是发展过程中人为因素造成的问题。尽管您无法完全没有它，但如果您编写“干净”的代码并尽可能负责任和专业地处理开发过程，则可以尽可能减少技术债务。这就是我们对大家的祝愿！