День 2529. #ЗаметкиНаПолях
Технический Долг — Миф, Созданный Плохими Менеджерами. Начало
Тысячи статей, выступлений на конференциях и десятки книг были посвящены техническому долгу, проповедованию принципов чистого кода и надёжной архитектуры. Разработчиков учили, как его избегать, гасить, как вести переговоры с менеджерами.
В чём проблема? Не в практиках — они по-прежнему хороши. А вот технический долг не просто неправильно понимается; это принципиально неверная метафора, которая искажает наше представление о разработке ПО. И что хуже всего, мы продолжаем использовать её, потому что это единственная финансовая метафора, понятная руководителям, а это значит, что мы застряли в объяснении инженерных проблем в терминах, которые маскируют то, что происходит на самом деле.

Проблема с метафорой
Уорд Каннингем в 1992 году ввёл термин «технический долг» для описания конкретной ситуации: преднамеренный выбор быстрой реализации с пониманием того, что позже её нужно будет переписать. Как и финансовый долг, вы берёте время взаймы сейчас с обещанием вернуть его с процентами.

Но вот что на самом деле происходит в большинстве организаций:
Менеджер: «Почему эта функция так долго разрабатывается? Я думал, вы сказали, что она будет готова за две недели?»
Инженер: «Ну, у нас много технического долга, который нужно преодолеть…»
М: «Так почему вы не писали более качественный код с самого начала?»

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

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

Что происходит с техническим долгом:
М: «Нам нужно выпустить это к пятнице для демонстрации инвесторам».
И: «Этого времени недостаточно, чтобы сделать это как следует. Нам понадобится как минимум три недели, чтобы все сделать правильно».
М: «Сделайте так, чтобы это работало. Мне все равно, как».
[Три месяца спустя]
М: «Этот код — полный бардак».

Видите проблему? Инженер ничего не «заимствовал». Он не выбирал долг. Ему поставили невыполнимые задачи, и он сделал всё, что мог. А теперь его обвиняют в «процентах». Это не технический долг. Это технические последствия решений руководства.

Любой код стареет (это не долг, это энтропия)
Ещё одна странность - называть любой старый код «техническим долгом». Ваш 4-летний код, использующий .NET 6 вместо последней версии, — это не «долг». API, возвращающий XML вместо GraphQL, — это не «долг». Монолит, который все теперь хотели бы видеть в виде микросервисов, — это не «долг». Это просто код, существующий во времени.

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

Называть это «долгом» подразумевает, что кто-то совершил ошибку. Это подразумевает халатность. Это подразумевает, что, если бы инженеры были умнее, дальновиднее, компетентнее, этой проблемы не было бы. Но так ПО не работает. Так не работает ничего. Вы не можете предсказать будущее. Невозможно создавать решения, отвечающие требованиям, которых ещё не существует. И даже если бы это было возможно, вы бы переусложнили систему и потратили время на создание гибкости, которая вам никогда не понадобится.

Продолжение следует…

Источник: https://dev.to/adamthedeveloper/technical-debt-is-a-myth-created-by-bad-managers-2l3k