День 1496. #ProjectManagement Хватит Говорить: «Технический Долг». Начало Представления людей о «техническом долге» немного отличаются. - Мы должны были выпустить эту функцию три недели назад. - Один разработчик застрял в обновлении фреймворка. Другой застрял при реорганизации флагов функций. Третьему нужно было изучить давно заброшенный репозиторий, чтобы внести изменения в базу данных. Команда зарывается. Каждый выпуск новой функции будет выглядеть так, пока нам не дадут несколько недель, чтобы расплатиться с техническим долгом. Мы понятия не имеем, как заставить бизнес задуматься об этом. Звучит знакомо? Это разочаровывающий разговор. Но мы часто сами приводим себя в эту ситуацию. Мы пытаемся объединить бизнесменов, дизайнеров, продакт-менеджеров и инженеров, используя фразу «технический долг». Но для каждого эта фраза означает своё. Спросите 10 технических специалистов, что такое технический долг, скорее всего получите 5-7 разных ответов. Все связывают этот термин с чувством — обычно разочарованием, — но у них нет точного представления о том, откуда это чувство берется. Поэтому они навешивают этот термин на всё, что их беспокоит или пугает. Дизайнеры говорят, что дизайн выглядит не так, как они планировали. Менеджеры скажут, что это задержки в графике релизов функций. Ответы разработчиков будут вариациями на тему «плохого кода». Когда на собрании звучит термин «технический долг», все расстраиваются, но никто не слушает. Каждый предполагает, что знает, о чём все говорят, но их индивидуальные представления немного отличаются. Для бизнеса это звучит, будто инженеры просят три недели без обязательств по выпуску каких-либо функций. В последний раз, когда им их давали: спустя месяц команда снова отставала, и в их понимании профита от этого ноль. Мы, инженеры, должны скорректировать терминологию. Приравнивание технического долга к просто плохому коду имеет несколько проблем. 1. Позволяет думать, что предыдущие разработчики просто халтурили, что нетактично, но нормально, пока мы не поймем, что на самом деле существовало ограничение, о котором мы не знали. Это ограничение объясняет отвратительные характеристики кода, а также мешает нам реализовать наше гениальное решение. Одна команда бесконечно жаловалась на то, что для получения информации о клиентах требуется запрос из двух разных таблиц. Они думали, что эта структура унаследована и не менялась из-за обратной совместимости. Потратив кучу времени на критику дизайна базы и способы её исправления, команда поняла, что их план… незаконен. Из соображений конфиденциальности в их отрасли хранение этих двух конкретных частей личных данных в одной таблице является незаконным. К счастью, менеджер продукта упомянул о ситуации юристу компании до того, как команда инженеров зашла слишком далеко. 2. Приравнивание технического долга к просто плохому коду создаёт впечатление, что, если мы просто напишем хороший код, у нас не будет технического долга. Поэтому мы не тратим время на обзоры, тесты и комментарии. И через год мы там же, с чего начинали. 3. Позволяет нам путать «этот код не соответствует моим личным предпочтениям» с «этот код является проблемой» — что, опять же, нормально, пока мы не ограничены во времени. Мы тратим «неделю технического долга», занимаясь рефакторингами, вместо того чтобы что-то исправлять. Инженеры любят рефакторить код, чтобы он выглядел лучше. В итоге работать с кодом не становится легче, чем раньше: код просто другой, и никто, кроме автора, больше его не знает. Это одна из основных причин того, что недели «выплаты технического долга» часто мало или совсем ничего не прибавляют к скорости команды после них. Окончание следует… Источник: https://stackoverflow.blog/2023/02/27/stop-saying-technical-debt/