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

Что-то написать про техдолг хотелось давно, в закладках копились статьи, цитаты и видосики (настолько, что один видос на года стал обложкой “смотреть позже” на ютубе), но все не доходили руки. И может, это к лучшему, потому что за последние лет 5 и опыта стало немного больше, и мои взгляды на эту тему немного изменились.

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

Что такое “техдолг” #

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

Идеалисты, пуристы и прочие архитекторы в составе определения могут указать, что техдолг — это намеренное, задокументированное и обоснованное решение в чистом коде, о котором извещен бизнес, и по которому есть план исправлений, а все остальное — это “cruft” (хлам/говнокод). Подобного мнения придерживается, например, Роберт Мартин. Звучит конечно классно, но, увы, очень уж нереалистично: если решение принимается из-за сжатых сроков, то код высочайшего качества производить никто не будет. Чуть более мягкий вариант описывает техдолг как последствия решений и компромиссов, когда жертвуют качеством ради скорости. Но тут подразумевается, что кто-то это решение осознанно делает и понимает все последствия.

На другом конце спектра — очень широкие определения уровня “все что не нравится разработчику” или “любое несоответствие системы оптимальному состоянию”. У них проблема в том, что их широта не позволяет нормально использовать их при обсуждении улучшений и приоритизации. Да и легко попасть во вкусовщину — одному не нравится, другому ­— норм, бизнесу вообще до кода дела нет, и ему совершенно неясно, а как это повлияет на пользователя, что у вас теперь форматирование будет другим. Иногда можно встретить уточнения, что техдолг — это проблема в технике (код, тесты, архитектура, инфраструктура, документация и т.п.), которая несет расходы и/или последствия.

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

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

Где-то по середине спектра Фаулер делит область на квадранты по двум осям: явность (команда может видеть проблему, а может не осознавать ее) и намеренность (техдолг может быть следствием решения/компромисса, а может возникнуть сам по себе). Похожее разделение найти можно найти у Крухтена и Макконнелла. Но это уже больше похоже на классификацию причин возникновения техдолга, чем на его определение. Определение техдолга таким образом, на мой взгляд, не дает понимания его сути.

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

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

Если учесть, что мы говорим о техническом долге, то изменение бизнес-контекста стоит исключить, оставим продуктовые вопросы бизнесу. При этом о техдолге имеет смысл рассуждать только если он как-то измеримо влияет на поведение или развитие системы. По факту, мы говорим про нефункциональные требования, которые в себя включают как аспекты эксплуатации системы (производительность, безопасность, надежность и т.п) так и аспекты ее эволюции (тестируемость, развитие (в т.ч. изменение кода), расширяемость и т.п.). И если проблемы с эксплуатацией — это дефекты/баги, то проблемы эволюции обычно напрямую связаны с понятием техдолга. При этом важно помнить, что нефункциональные требования должны быть конкретны и измеримы, а всякая вкусовщина (“код должно быть приятно писать”) сюда не включается. Причины возникновения не так уж важны: если помоечный код тяжело изменять, то как-то пофиг, кто какие там решения принимал 5 лет назад.

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

Что не является техдолгом #

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

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

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

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

Откровенный говнокод — однострочные переменные, спагетти, форматирование кто в лес, кто по дрова, функции на 200 тысяч строк и т.п. Это отсутствие базового качества. Настройте наконец сборку и/или среду разработки на форматирование и какие-то базовые вещи, чтобы даже не вспоминать про это.

Что-то, что может не нравится (некоторым) разработчикам, но не связано с развитием системы или не мешает ему. Например, вопросы решения споров уровня табы против пробелов или какой редактор использовать. Если это не проблема, которая хоть сколько-нибудь существенно влияет на систему, то и внимание ей уделять нет смысла.

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

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

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

Как возникает техдолг #

Подробную классификацию на эту тему можно посмотреть в научных статьях (1, 2) или у тех же Макконела и Крухтена. Но мне кажется, что слишком подробно онтологию эту вести мало кому нужно на практике, да и с учетом неустоявшегося определения тяжело будет это делать.

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

Осознанное решение #

“Настоящий” техдолг по мнению многих: четко оценили проблему, взвесили варианты решения, осознали последствия каждого из них, вдумчиво обосновали, задокументировали и вообще все сделали по уму. Берем “долг” для решения текущих проблем, позже выплачиваем, отличный инструмент взрослых дядек-бизнесменов. Примерно в таком виде изначально метафора и зародилась. И да, это можно встретить на практике, но довольно малый процент техдолга появляется именно таким образом.

Подобные решения можно условно поделить на тактические (“исправим в следующем релизе”) и стратегические (“этот костыль пока не трогаем, скоро будет работа X, в рамках нее поправим”).

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

Причем не всегда менеджеры требуют скорость только ради скорости. Иногда подобные решения — это просто выживание: если не успеем сделать, то бизнес завтра может перестать существовать или влететь на большие бабки. Опять же, бывают внешние факторы, с которыми ничего не поделаешь. Например, в моей практике было, что обновляется законодательство, и прям НАДО к определенному сроку (дата вступления закона в силу) успеть что-то сделать.

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

Организационные проблемы могут проявляться и через межкомандное взаимодействие. Например, когда надо сделать изменения в нескольких компонентах с разными владельцами и/или нужны какие-нибудь согласования, часто можно попасть в ситуацию, когда команда делает костыль, который не требует всего этого (см. Закон Конвея).

Следствие других решений #

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

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

А такие маленькие и изолированные тактические изменения — путь к смерти от тысячи порезов. Каждое изменение само по себе может быть адекватным (например, “добавим еще одно поле к объекту”), но в совокупности у вас может получится какое-то аморфное непотребство с огромной “наносной” сложностью. А еще кучей мелких инкрементов очень легко сделать задачу не до конца. Чтобы такое предотвращать, у команды должна быть внятная стратегия, а некоторые команды даже текущие приоритеты могут озвучить с трудом. Классический пример — делаем какую-нибудь миграцию, смигрировали 80% за 20% усилий, остаток положили в бэклог, потому что бизнесу ща срочно надо другое. Так можно годами жить с чемоданом без ручки или двумя параллельно работающими системами.

Могут быть просто конченые процессы. Например, если любой ПР на рефакторинг должен быть отдельно от фичи — угадайте, как это повлияет на количество рефакторинга?

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

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

Продолжать можно еще долго; если есть какая-то дисфункция на уровне организации, то и в систему она рано или поздно протечет.

Внешние (неконтролируемые) изменения #

Иногда техдолг появляется “сам по себе”, и не является следствием каких-либо решений команды или даже компании. Просто поменялась окружающая среда и внешние обстоятельства.

Например, на уровне компании приняли какое-то глобальное решение: о переезде на другой стек технологий, об устаревании вашего текущего, какие-то глобальные архитектурные правила, переезд из собственных серверов в облако или из одного облако в другое и т.п. Все, что написано “по-старому”, автоматом становится техдолгом.

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

Наконец, сама индустрия может двинуться вперед и неявные требования, связанные с лучшими практиками, могут быть замещены более новыми из-за обнаруженных изъянов. Например, XML был вполне себе адекватным стандартным решением для своего времени, но будет считаться техдолгом во многих местах сейчас (разумеется, не без нюансов и “зависит от задачи”).

Какие последствия влечет за собой большой техдолг #

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

Даже само знание о термине открывает форточку манипуляций: катим в прод говнокод, объявляем “техдолгом” и “тактическим решением”, гордимся визионерством, никогда не фиксим. Повторяем несколько раз → качество летит в помойку. Например, сегодня добавили “просто еще одно поле” к объекту, потому что это “проще”, и пофиг, что оно к этой модели не имеет отношения; а через полгода лишних полей уже десяток, и отделить их — целая история. Из-за отсутствия четкого определения очень легко любую проблему или недостаток обзывать “техдолгом”, срезая углы.

Ниже скорость разработки. Качественный код — это как раз такой, который легко поддерживать и развивать, поэтому большое количество техдолга способствует существенному снижению скорости на всех этапах разработки. Код — лапша и нагромождение лишних абстракций? Разработчик будет дольше искать место для изменений. Архитектура конченая? В новом компоненте будем делать нетривиальные приседания, чтобы обойти ее ограничения (получим еще более конченную архитектуру). Деплой — 500 строк кода, написанных 5 лет назад уволившимся разрабом, который даже не шарил в девопсе? Удачи добавить туда еще один простой шаг. Как следствие — стоимость разработки увеличивается.

Больше багов. Если тяжелее сделать “правильные” изменения, то значит в среднем изменения будут с дефектами. Например, в запутанном коде легко допустить ошибку — как по незнанию, так и по непониманию. Нет автотестов и тестируем руками полтора сценария? Сегодня отвалится одно, починим, завтра отвалится другое (можно повторять по кругу).

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

Пустая трата времени. Больше багов — больше времени тратится на их сопровождение и исправление. Иногда доходит до абсурда: суммарное время на обсуждение бага и его деприоритизацию может превысить время на его исправление. Кучу времени можно спустить на ручной труд по “временному” процессу, вместо того, чтобы потратить время на его автоматизацию, хотя бы частичную. Поскольку нет четкого понимания, что такое “техдолг”, можно потратить много времени, героически борясь с “техдолгом”, который не был проблемой (например, вкусовщина в коде) или не был проблемой, стоящей внимания (например, в проекте используется фреймворк не самой новой версии).

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

Продукт становится менее предсказуемым — непонятно, какие последствия повлечет собой исправление бага или добавление фичи; нет уверенности, что прод завтра не упадет; “покрасить кнопку” может занять от 5 минут до 2 недель.

Появляется страх вносить изменения: “работает — не трогай”. Кто его знает, что может отвалиться в этот раз, особенно если в предыдущие разы что-то поломалось. Иногда так можно создать больше техдолга в попытке изолировать новые изменения от существующей базы ради снижения риска. И есть несколько страшилок, когда бизнес помер от техдолга, например, про Knight Capital, которая потеряла из-за мертвого кода 450 млн. долларов.

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

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

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

У последствий можно отметить много параллелей с вариантами возникновения техдолга. Техдолг может существовать годами, и чем дольше он в коде, тем обычно тяжелее от него избавиться. Некоторые костыли настолько эпичные, что могут иметь свое имя (например, в одной из компании он носил фамилию придумавшего его архитектора — “костыль Иванова”). Так что технический долг будет только расти, даже если нет никаких новых его источников.

Как бороться #

Чтобы эффективно бороться с техдолгом, надо сначала понять, что это вообще такое. После этого — повысить видимость техдолга, чтобы это было не ощущение или знание в головах, а что-то осязаемое. Обнаружилась какая-то значительная проблема — стоит завести тикет, чтобы потом можно было его предметно обсудить или добавить детали. Аналогично, когда понимаем, что создаем технический долг, то лучше сразу создавать тикет на его устранение или документировать решение в каком-нибудь ADR.

Следующий шаг — оценить, с чем стоит бороться в первую очередь, т.е. приоритизировать. Тут те же проблемы, что и с приоритезацией фич: неясно, как мерить пользу (чаще всего это “прирост продуктивности”, которую никто не знает как измерять), долго оценивать точно и слишком много неявных факторов. К одной табличке с цифрами тяжело это свести, скорее всего придется полагаться на “экспертную оценку”, но можно составить чек-лист. При этом часть определения приоритета — понимание цели, чтобы было не тупо “давайте отрефакторим” или “давайте перепишем это говно”, а четкая цель: зачем именно это нужно и что изменится с точки зрения системы в целом.

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

Дальнейшее развитие событий зависит от того, насколько бизнес вовлечен в эти ваши технические штучки.

Если любую задачу надо обосновывать для бизнеса, то надо научиться продавать задачи, связанные с уменьшением техдолга. Для этого надо связать техническую пользу с пользой для бизнеса. Условно, не “у нас кодовая база по папкам плохо разбита и это плохо”, а “очень много времени тратим на поиск места, где сделать изменения, если поправим, будем делать фичи быстрее”. Некоторые советуют использовать метафору по максимуму и считать все в деньгах, но, на мой взгляд, это какая-то ерунда. Бизнес не всегда может фичи в деньгах посчитать, а аморфные технические нюансы на деньги вообще очень криво ложатся за исключением единичных случаев.

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

1. Выделенный спринт. Это утопия: если у вашего бизнеса нет большого бэклога с продуктовыми задачами, то скоро он загнется, а если он все-таки есть, то должно случиться что-то исключительное, чтобы прям целый спринт отдали чисто под абстрактный техдолг. Такое может быть после большого инцидента, но на регулярной основе подобное звучит очень сомнительно.
2. 10-20% процентов времени с барского плеча выделяется на техдолг. Популярная стратегия, но на практике работает хреново: то появится срочная бизнес задачка, и эта квота будет первой в очереди на вылет, то выполнение других задач растянется (ну серьезно, вы видели, чтобы все в запланированные сроки укладывалось?). Что-то в таком варианте будет двигаться, но не очень быстро.
3. Как вариация предыдущего варианта — “если останется время в спринте”. Спойлер: его не останется, а если останется, то просто в следующем спринте больше фич дадут.
4. “Поправим в следующем спринте” для тактического решения — кек, см. миллион мемов на эту тему. Если договоренность сработала — почет и уважение бизнес-лидерам, но на практике встречается редко, соблазн двигаться дальше (“работает же”) слишком велик.
5. Выделенный человек, aka “дежурный по говну”, периодически ротировать. Проблемы будут скорее всего те же, что у вариантов 2 и 3, а еще иногда на дежурного могут навесить вдобавок деплои, on-call или техподдержку.
6. “налог на фичу” — оценка задачи искусственно раздувается. Основных проблем тут две: мелкими инкрементами тяжело добиться существенного прогресса и исправить архитектуру, да и без внятной цели это будет просто случайное улучшательство в большинстве случаев.

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

Наконец, если бизнес активно блокирует всю нефункциональную разработку или продажа улучшений провалилась — придется уходить в подполье. Это как “налог на фичу”, только бизнес об этом знать не будет. Правда в один момент придется реально объяснять, почему для какой-то фигни нужно несколько дней:)

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

Простейший пример — правило бойскаута. Но с ним главное не переборщить и не уйти в перфекционизм. Не надо тешить свой ОКР или убирать техдолг ради убирания техдолга: должна быть причина и усилия должны окупиться. Например, уборка во внутреннем микросервисе, который изменяется раз в год, вряд ли себя окупит, а вот в активном коде с частыми изменениями стоит поддерживать чистоту.

Для полноты можно еще указать стратегию “не создавать техдолг”. Я надеюсь, что после раздела про пути возникновения техдолга очевидно, что это такая же хрень как и “делать все идеально”. Однако есть на просторах интернета люди, которые настолько верят в aGiLe, что думают, что он позволяет бороться с техдолгом сразу после его появления.

А нужно ли вообще бороться? #

Стоит ли вообще эта борьба вложенных усилий? Кому вообще на этот техдолг не пофиг? Если в наше время Apple может быть пофиг на дизайн, а код пишет ИИ, то может, и не надо париться?

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

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

Фича может быть удалена в следующем релизе — что толку думать о ее качестве? “Код становится легаси сразу после его написания”. Может, проще подождать, когда код пойдет на выброс? Или ИИ станет еще лучше и отрефакторит нормально?

А пресловутое легаси? Для кого-то это говнокод, но по факту — это колоссальный массив накопленного опыта, проверенный на практике и адаптированный к конкретным обстоятельствам бизнеса. Работает — не трогай!

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

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

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

Итого #

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