Comments 7
Приятно, когда люди не имеющий значительного технического бэкграунда думают о техническом долге :)
И еще более приятно, что они думают о том, что с ним нужно бороться, чтобы добиться его уменьшения
-----------------
Остальное в целом ... честно говоря, статья про "все хорошее" против "всего плохого". Причем тут "тестирование", DoD/DoR, метрики, документация, ... такое ощущение, що надо было что-то писать, и в итоге просто объем заполнялся чем-то обо всем.
Все условно проще и очевиднее
Есть функциональные требования к продукту. Они к техническому долгу как раз не имеют отношения. Сразу забыли.
Есть нефункциональные требования, невыполнение которых в полном объеме (в полном не вообще, а для конккретного продукта в конкретном окружении, где он работает). Где-то невыполнили - получили потенциальную проблему. Потенциальную потому, что может так случится, что она не выстрелит. К примеру уязвимость по безопасности. Она есть, но не факт, что кому-то придет в голову ее эксплуатировать.
Почему мы говорим о долге? Потому что требования были, но они не выполнены. но теоретическки оплачены. Значит мы "должны".
Но мне кажется есть важный момент. Если нефункциональное требование "лежит на столе" - это не технический долг. Это баг. Потому что заказчик или сама команда может провести соответствующий тест и его выявитиь. К примеру, есть требования по количеству запросов, которые в единицу времени должна вытягивать система на определенном конфиге, а она задолго до этого склеивает ласты, условно не нагрев камень до 100%. Это баг. Это не долг, особенно есть перформанс тесты были запланированы
Или вы подписались по 70% покрытия кода юнит-тестами и успешный отчет сканера кода - ан нет. Нету. Тоже это не долг, а просто бага. Требование есть и оно нереализовано. Тут не о чем говорить, особенно в ситуации, когда это требование заказчика.
----------------------
Долг - это невыполнение неявных требований. Либо таких, которые сложно проверить. К примеру, extensibility. В общем, сложно проверить. Но когда выстрелит какой-то кейс - сразу возникнет вопрос, а почему так много нулей в оценке, а зачем вам так много регресса. Вы же обещали что это можно будет прикрутить в пол-оборота.
Почему возникает - понятно. Где-то в коде пошли по кривой дорожке и/или сознательно захардкодили больше, чем того требовалось, зная о будущем развитии продукта. И вот это уже долг, потому что мы знали, но тогда делать параметрическое решение было долго, быстрее было закодить только этой кейс напрямую. Это как пример.
Также надо заметить, сам по себе косяк может не быть проблемой. Например мы осознанно пошли, заказчик в курсе о последствиях. Это тоже не долго, так как бы открыто пришли к тому, что тогда так было лучше.
Проблема, это когда мы осознанно и случайно накосячили, а теперь у нас по срокам/деньгам не складывается бюджет. И вот тут надо что-то делать.
----------------------
Конечно можно натягивать сову на глобус, виноватику глаз на опу, а любой косяк команды на термин "технический долг" - но тогда получится про "все хорошее против всего плохого". Но как по мне, если его сузить до "осознанного" компромиса - тогда станет понятно, как именно с ним в таком виде работать.
А именно
приняли решение о компромисе ради краткосрочной выгоды
записали последствия
в определенный момент, когда жить с последствиями стало дороже, чем исправлять - поставили вопрос
Иначе ... это бессмысленное абстрактное знание ни о чем
Тот замечательный случай, когда комментарий гораздо лучше расккрывает тему, чем статья
Не профессиональный программист, поэтому могу ошибаться в сути или в терминологии.
С моей точки зрения, существует ещё одна причина появления технического долга - неполная информация. То есть мы изначально считали как-то по одному и с этим пониманием строили проект. А в процессе разработки ли, тестирования ли или эксплуатации оказалось, что что-то лучше было сделать по-другому, и появляется необходимость рефакторинга. Это тоже то, что не является новой фичой и не приносит денег напрямую, но может повлиять на сроки внедрения новых фичей, на стабильность продукта, ресурсы на поддержку и т.п.
Это скорее ошибка во время сбора требования. Просто что-то не собрали.
Или бывает прилетает что-то извне, риск какой-то сработал, или изменение законодательства к примеру. Тогда это риск менеджмент.
Но, как я писал в комментарии ... я бы рассматривал долг, как нечто что мы взяли взаймы и в какой-то момент надо отдавать с процентами. Что интересно, проценты тоже почти всегда так или иначе возникают, так как мы сначала накостылили (потратили ресурс), а потом надо костыль выкинуть и делать по хорошему.
Просто попытка все назвать "тех. долгом", как в статье банально приводит к тому, что это определение становится всеобемлюшим вроде "солнце встает на востоке", и соответственно бесполезным (хотя кто-то может всмомнить, что в южном полушарии все не так, но это уже не важно). Правильнее это расматривать максимально узко, чтобы именно с ним работать правильно
А отдельно работать с требованиями, рисками, тестированием. Потому что оно все похоже только с "большого" расстояния.
Позанудствую немного, но в южном полушарии солнце тоже встаёт на востоке)
Да, точно. Оно просто в другую сторону идет :)
В какую другую? На запад же. А лево-право тут сложно применять.
Вот вы щас техдолг себе и сделали на ровном месте. Не определили систему сторон света и привязали к рукам наблюдателя. Потому что по первоначальной задаче он неподвижный и наблюдает солнце со своего полушария лицом к противоположному полюсу. А потом крутим фичу чтобы наблюдатель вертелся и - надо делать нормально.
Технический долг — тихий убийца