Что такое технический долг?

Что такое технический долг? Примеры, профилактика и лучшие практики

Сожержание

Аннотация

Большинству разработчиков программного обеспечения знакома проблема технического долга, но это менее верно для тех, кто не занимается программированием.

Однако эту концепцию важно понимать, поскольку она применима не только к программированию, но и к широкому спектру сценариев, в которых краткосрочные решения могут иметь долгосрочные последствия. Ниже приведены примеры технического долга и лучшие практики, которые вам необходимо знать.

Что такое технический долг?

Технический долг возникает, когда команды разработчиков программного обеспечения ставят скорость доставки выше оптимального качества кода.

Часто это делается намеренно. Пользователю может срочно понадобиться функциональность, поэтому разработчики решают развернуть «достаточно хороший» код с намерением исправить его позже.

Метафора долга уместна. Когда кто-то берет на себя долг, это часто происходит потому, что финансовые ресурсы необходимы на краткосрочной основе. Однако это создает дополнительные затраты в будущем, когда этот долг придется погасить.

Технический долг возникает, когда команды разработчиков ставят скорость доставки выше оптимального качества кода.

Технический долг работает аналогичным образом, обменивая выгоду на дополнительную работу в будущем.

Если код в конечном итоге не будет пересмотрен и исправлен, он может стать проблемой, так же как могут начисляться проценты и штрафы, если платежи по кредиту не производятся.

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

Примеры технического долга

Классическим примером технического долга является проблема 2000 года (Y2K).

Многие разработчики программного обеспечения в 1960-х и 1970-х годах предпочитали экономить драгоценную память, сохраняя даты в виде двух цифр: «73» вместо «1973».

Такая практика продолжалась в течение многих лет, даже несмотря на то, что цены на память падали. Многие из этих программ были внедрены в операционный бизнес и использовались гораздо дольше, чем кто-либо ожидал.

По мере приближения 2000 года тысячи предприятий и правительственных учреждений осознали, что расчеты дат в массовом масштабе окажутся неудачными. Это привело к лихорадочным усилиям по очистке, стоимость которых оценивается в 100 миллиардов долларов .

Технический долг не ограничивается программным обеспечением. Например, лучшая практика в области кибербезопасности — предоставлять права доступа к файлам ролям внутри организации, а не отдельным лицам.

Предположим, помощник по административным вопросам получает разрешение от начальника на получение временного доступа к конфиденциальным документам, которые ему обычно не разрешают просматривать. Если ИТ-организация предоставляет исключение и не может его отозвать позже, это означает, что она предоставила постоянный доступ к конфиденциальным документам. В конечном итоге учетная запись может быть скомпрометирована и стать уязвимой.

Каковы недостатки технического долга?

Если краткосрочные исправления быстро рефакторингуются и разработчики знают, как справиться с техническим долгом, недостатков мало. Это может даже принести пользу, поскольку это может позволить бизнесу быстро реагировать на возможности или проблемы.

Риск возрастает, когда долги наслаиваются друг на друга.

Быстрые исправления могут быть плохо документированы или не документированы вообще. А когда люди, которые выполняли быстрые исправления, уходят, в компании может не остаться никого, кто знает, как должен работать код или даже о том, что быстрые исправления существуют.

Улучшения или изменения могут создавать непреднамеренные конфликты, которые приводят к сбоям или медленной работе программ. Инновации замедляются, поскольку организации не могут внести улучшения из-за страха, что изменения сломают приложение.

Какие виды технического долга существуют?

Двумя основными категориями технического долга являются преднамеренный и непреднамеренный.

Намеренный технический это тот долг который берется на себя сознательно и стратегически.

Непреднамеренный технический возникает как «нестратегический результат плохой работы».

В 2014 году группа ученых разработала таксономию технического долга , которая включает 13 различных типов, в том числе:

  • Архитектурный долг(Architecture debt)
  • Долга кода(Code debt)
  • Долг ошибок(Defect debt)
  • Долг проектировки(Design debt)
  • Долг процессов(Process debt)
  • Долг тестирорвания(Test debt)

Эта классификация полезна, поскольку она охватывает все области, в которых краткосрочное мышление может создать долгосрочные проблемы.

Как возникает технический долг?

Намеренный технический долг

Намеренный технический долг — это сознательное решение, которое должно быть задокументировано и запланировано для рефакторинга.

Например: у регионального менеджера по продажам есть крайний срок для создания отчета, который его платформа не может предоставить. Поэтому он внедрил программу создания отчетов с открытым исходным кодом, чтобы уложиться в срок. Это технический долг.

Однако если команда разработчиков выделяет ресурсы для удаления средства создания отчетов с открытым исходным кодом и изменения основной системы отчетов, это является намеренным техническим долгом.

Непреднамеренный технический долг

Непреднамеренный технический долг возникает, когда изменения или дополнения вносятся из соображений целесообразности и без преднамеренных планов по рефакторингу кода.

Это также может быть результатом плохих проектных решений, вызванных недостатком знаний или несоблюдением стандартов разработки. Непреднамеренный технический долг в области тестирования возникает, когда наборы тестов неполны или тестирование сокращено или пропущено ради удобства.

Задолженность по документации

Задолженность по документации является обычным явлением и возникает, когда разработчики слишком спешат тщательно документировать свой код.

В долгосрочной перспективе это может стать большой проблемой, если человек уйдет из компании и не сможет оставить след, который другие смогут использовать для понимания его кода. Задолженность по документации стала основной причиной проблемы 2000 года.

Инфраструктурный долг

Долг инфраструктуры возникает, когда приложения создаются с учетом определенных компонентов инфраструктуры, таких как базы данных и файловые системы. Если такие зависимости не задокументированы и компания переходит на новую инфраструктуру, приложение может не работать.

Каковы признаки технического долга?

Предупреждающими признаками технического долга являются:

  • Проекты застревают из-за того, что разработчики не имеют представления о кодовой базе.
  • Выскакивают ошибки, которые сложно исправить из-за сложности или отсутствия документации.
  • Исправления ошибок, которые создают новые ошибки или постоянное снижение производительности.

Как управлять и предотвращать технический долг

Знание того, как справиться с техническим долгом, начинается с разумных методов разработки. В среде DevOps это включает тестирование как со сдвигом влево, так и сдвигом вправо.

  • Сдвиг-влево при тестировании перемещает процесс тестирования на более ранние стадии цикла разработки и на протяжении всего цикла, так что проблемы можно предвидеть и решить до того, как они будут внедрены в производство.
  • Тестирование со сдвигом вправо направлено на получение обратной связи после того, как приложения будут запущены в производство, чтобы можно было обнаружить ошибки на ранней стадии и исправить их до того, как программное обеспечение получит широкое распространение. Они создают ограждения, которые предотвращают чрезмерный рост проблем.

Обходные пути, которые создают технический долг, неизбежны и часто необходимы. Однако важно, чтобы разработчики документировали их, включая причины, по которым были применены хаки, и инструкции по их устранению.

Регулярные проверки существующего кода также могут позволить членам команды проверять работу друг друга и выявлять пробелы или нарушения в документации.

Почему все это важно?

Говорят, что каждая компания теперь является компанией-разработчиком программного обеспечения. Даже предприятия тяжелой промышленности стремятся собирать данные, чтобы их клиенты могли получать больше пользы от покупаемых ими продуктов.

Ежегодно создается больше программного обеспечения, чем было создано за всю историю вычислений, и эта тенденция ускоряется.

В то же время организации-разработчики испытывают большее, чем когда-либо, давление, требующее быстрого запуска проектов в производство. Для спешащих разработчиков естественно срезать углы, а менеджеры проектов должны понимать и укреплять свои команды, что тестирование и документация — это не одноразовые вещи.

Каковы лучшие практики?

По мере того, как организации внедряют методы DevOps, им следует разъяснять, что такое технический долг, и применять гибкую тактику для управления им. Это может включать в себя реализацию:

  • Тестирование сдвига вправо и сдвига влево
  • Методы A/B и канареечного тестирования для выявления проблем до того, как они выйдут из-под контроля.

Коллегиальные проверки кода позволяют по-новому взглянуть на работу разработчиков. Разработчики должны работать с последовательным и ограниченным набором инструментов и языков и иметь контрольный список задач, которые необходимо выполнить на каждом этапе.

Эффективная организация DevOps дает разработчикам большую свободу выбора того, как им создавать свои творения, но также обеспечивает ограждения, гарантирующие, что они не выйдут из-под контроля.

Какие инструменты могут использовать компании для предотвращения технического долга?

Практики, изложенные выше, являются хорошим началом. Дополнительные преимущества могут быть реализованы за счет:

  • Использование автоматического тестирования для запуска нескольких циклов отладки при каждом изменении кода при каждом изменении модуля.
  • Создание надежных процедур структуры кода, включая обязательную документацию, для защиты от обходных путей.
  • Использование инструментов управления проектами, позволяющих командам видеть состояние работы каждого.

Программисты работают в командах по два человека, чтобы они могли понимать решения друг друга. Все больший объем программного обеспечения пишется с использованием инструментов low-code и no-code. Они в значительной степени самодокументируются, поскольку блок-схемы и методы перетаскивания позволяют представить визуальное представление логики и желаемых результатов.

Применяя эти инструменты для профессиональной разработки программного обеспечения, организации могут извлечь выгоду из этих функций самодокументирования. Менеджеры по разработке должны поощрять свои команды рассматривать low-code/no-code как повышение производительности, а не замену их элегантных творений.

Comments

comments powered by Disqus