Почему технический долг неизбежен, и это не вина разработчиков — обсуждаем мнения

Привет, Tproger. Мы облачный провайдер T1 Cloud. В своём блоге планируем рассказывать об актуальных темах из мира ИТ, включая системное администрирование, облачные технологии и разработку. Подписывайтесь, чтобы не пропустить всё самое интересное и полезное.

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

У всех на слуху

Понятие «технический долг» ввёл пионер в области экстремального программирования и изобретатель технологии wiki Уорд Каннингем ещё в начале 90-х. Этой метафорой он обозначил компромисс, на который идут разработчики при написании кода, чтобы закончить продукт в установленные сроки.

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

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

На задачи рефакторинга компании по всему миру выделяют порядка 85 миллиардов долларов ежегодно. И о причинах появления долга кодинга до сих пор идут дискуссии — например, часть специалистов убеждена, что в этом виноваты сами разработчики. Поэтому иногда метафору долга используют, чтобы оправдать низкое качество кода, несмотря на то что еще в 2009 году сам Уорд Каннингем высказался против подобной трактовки определения.

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

Однако в ИТ-сообществе есть и противоположная точка зрения — программистов нельзя винить в росте техдолга, и на практике всё значительно сложнее.

Технический долг неизбежен

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

К потенциальным источникам долга кодинга также относят управленческие просчёты, связанные с корпоративными методологиями и политиками. Технический долг подразумевает компромисс между скоростью и качеством кода, однако последняя величина — субъективная. Даже хорошая программа, написанная одним инженером, может не понравиться другому специалисту (более того, спустя время она может перестать устраивать самого автора).

Чтобы унифицировать процесс и избежать циклов бесконечного рефакторинга, принято использовать концепцию Definition of Done (DoD). Это — набор критериев, показывающих, что новая функциональность удовлетворяет внутренним требованиям и готова к использованию.

Но согласно исследованию аналитиков из компании Stepsize, разрабатывающей одноимённый баг-трекер, в большинстве организаций отсутствуют стандарты обработки технического долга. В то же время их внедрение способно ускорить запуск продуктов на 100%.

Ещё одна проблема, которая приводит к разрастанию долга кодинга — ошибки при внедрении гибких методологий. Например, этой точки зрения придерживается Мартин Фаулер, автор книг по архитектуре ПО и рефакторингу.

Компании пренебрегают созданием дорожной карты программного продукта и базовым набором практик, в итоге внедряют не agile, но «ложный agile» (иногда его называют «тёмным agile» или «тёмным scrum»). Менеджеры выстраивают неэффективные процессы, в результате страдают разработчики, которые тоже вынуждены принимать неоптимальные решения и копить технический долг.

Что дальше

Сам по себе технический долг не является чем-то плохим. В каком-то смысле это инструмент для достижения целей. По словам автора подкаста The Cloud Pod Джастина Бродли, он становится проблемой только в том случае, если команда разработки игнорирует последующий рефакторинг.

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

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

Например, для активного прототипирования и проверки гипотез в некоторых ситуациях подойдет подход low-code. Он подразумевает запуск и модификацию сервисов без написания кода — вместо языков программирования такие платформы используют графические интерфейсы с функциями drag-and-drop. Они стандартизируют стек и сокращают стоимость поддержки, а циклы разработки ускоряются.

Кстати, Gartner предсказывает, что к 2023 году больше половины средних и крупных корпораций будет работать с low-code платформами в том или ином формате.

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