День 2530. #ЗаметкиНаПолях
Технический Долг — Миф, Созданный Плохими Менеджерами. Продолжение
Начало

«Долг» - обычно правильное решение
Поговорим о том самом MVP, который вы создали 2 года назад. О том, который теперь «устарел», «нуждается в переработке», «тормозит ваше развитие».

Знаете, что ещё сделал этот MVP? Он подтвердил жизнеспособность бизнес-модели. Он привлек первую тысячу пользователей. Он сгенерировал доход, который позволяет нам вести этот разговор. Без этого «плохого кода» у вас ничего бы не было. Вы бы обанкротились в ожидании «идеальной архитектуры».

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

То, что менеджеры называют «долгом», инженеры называют «компромиссами»
Каждое инженерное решение — это компромисс. Не некоторые из них. Не большинство. Все!
- Скорость или гибкость;
- Простота или функциональность;
- Проверенные технологии или передовые решения;
- Разработка собственными силами или покупка;
- Монолитная архитектура или микросервисы;
- SQL или NoSQL;
- Покрытие тестами или скорость выпуска.
На эти вопросы нет «правильного» ответа. Есть только «правильный для нашего текущего контекста, ограничений и приоритетов». Хорошие менеджеры это понимают. Они участвуют в принятии этих решений. Они говорят что-то вроде: «Сейчас нас заботит скорость выпуска, потому что нам нужно проверить рынок. Мы вернемся к архитектуре, когда достигнем соответствия продукта рынку».
Плохие менеджеры говорят: «Просто заставьте это работать. Разберитесь».
А потом: «Почему так много технического долга?»

Реальная проблема: Накопление невежества
Вот что на самом деле происходит, когда менеджеры не понимают накопительного характера затрат на поддержку ПО:
Год 1: «Выпускайте быстро! Не беспокойтесь о идеальном коде!»
Год 2: «Почему новые функции требуют больше времени? Раньше мы выпускали их так быстро!»
Год 3: «Нам нужно остановить всю работу над функциями и переписать код».
Это не технический долг. Это непонимание руководством того, что поддержка ПО не бесплатна. Что каждая функция увеличивает площадь покрытия. Что каждая зависимость нуждается в обновлении. Что каждый API нуждается в версионировании.
Инженеры знали это. Они говорили вам. Вы не слушали, потому что были сосредоточены на показателях следующего квартала.

А что насчёт реального срезания углов?
Да, иногда инженеры действительно халтурят. Мы пропускаем написание тестов, жёстко кодируем значения, неправильно обрабатываем ошибки, копируем и вставляем вместо того, чтобы переиспользовать код. Но это почти всегда происходит из-за внешнего давления:
- «Нам это нужно для демонстрации завтра».
- «Клиент угрожает уйти, если мы не выпустим продукт на этой неделе».
- «Мы теряем деньги и нам нужна прибыль прямо сейчас».

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

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

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