Поддержка  •  Дневник  •  Без рекламы  •  О сайте  •  Реклама  •  Поставить баннер  •  Прислать  •  Хроника  •  Translate Гости: 17    Участники: 0 Авторизация Авторизация   Регистрация 
Метод Научного Тыка
RULVEN
Поиск  
Blackball iMag | интернет-журнал
Каталог


Начало » Разработка ПО » Технический долг. Как не обанкротиться

Технический долг. Как не обанкротиться


Опубликовано: март 2023 г.
Добавлено: Пн 27.05.2024 • Sergeant
Автор: Vlad Deriglazov
Источник: источник
Просмотров: 23
Комментарии: 0


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

Как появился этот долг? Мы его взяли что бы поставить заказчику функционал раньше, чем мы бы смогли, если бы не "заняли". Так же как бизнесмен берет кредит для своей бизнес идеи.

Проценты выплачиваются при выполнении задач. Многие встречали ситуацию когда продукт‑менеджер говорит: «Да тут небольшое изменение внести”, а разработчик пытается объяснить что там кривая архитектура и вообще все на костылях держится и нужен месяц на такую фичу. Разница между работой над конкретной фичей и реальными затратами с учетом костылей, является наш процент. И он постоянно растет, если не оплачивать основной долг.

Технический долг (ТД) как глыба льда под водой, невидимая для бизнеса. И цель разработчиков эту глыбу показать и устранить.

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

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

Варианты технического долга

  • 😎 Осознанный: осознанные компромиссные решения и костыли.
  • 🐞 Неосознанный: отсутствие стандартов, отсутствие контроля чистоты кодовой базы, неосознанные костыли.

🧐 Как уменьшить основной долг

  • Для начала нужно избавиться от неосознанных кредитов:
    • Развиваем команду
    • Внедряем стандарты написания кода
    • Проводим Code Review
  • Ставим задачи на приоритеты
    Необходимо сформировать бэклог задач и выдвигать на приоритеты их выполнение. Важно аргументировать, лучшим аргументом был постоянно увеличивающийся срок реализации простых с виду задач — разработчики знали, сколько сложных мест в коде им придётся обойти, сколько новых костылей расставить, и закладывали эти параметры в общую оценку задачи. После нескольких таких планирований продукт-менеджеры сами предлагали команде взять задачи на рефакторинг.
  • Встречаем сопротивление
    Одна из сложностей в отношении технического долга заключается в вовлечении бизнеса в принятие решений. Бизнесу сложно аргументировать. Задачи копятся но не выполняются.

    Предусматривайте ресурсы для работы с ТД. Самая распространённая модель — это 70% для обычной работы, 20% для технического долга и 10% для обучения/экспериментов.

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

⚖️ Инкрементный рефакторинг

Рефакторинг — это контролируемый процесс улучшения кода, без написания новой функциональности.

Контролируемый — подразумевает итерационный процесс улучшения.

💡 «Всегда оставляйте лагерь чище, чем он был до вас»

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

70/20 - из описания выше мы знаем 70% для обычной работы, 20% для технического долга и 10% для обучения/экспериментов. В случаи постепенного рефакторинга, 20% это будет буфер отклонения от бизнес задачи. Т.е. это то время на которое мы можем отклониться от сроков задачи в пользу устранения ТД. Эта модель может быть дикая по отношению к бизнесу, поэтому используйте ее с опаской.

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

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

Закон убывающей предельной полезности

Т. е. не следует тратить на рефакторинг много времени. Необходимо получить максимальную выгоду и вовремя остановиться.

🏅 Подведем итоги

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


Мне нравится 0   Мне не нравится 0



Комментарии

Чтобы добавить видео с YouTube, нужно написать [@youtube=xxxxx] , где xxxxx – ID видео.


Комментарии: 0
Нет ни одного комментария.
RSS-лента
Поделиться ссылкой:

Новое
Про модель, логику, ООП, разработку и остальное 2 дня назад, 09:03
Про модель, логику, ООП, разработку и остальное
15 простых рецептов куриных ножек с картошкой в духовке Сб 15.06.2024
15 простых рецептов куриных ножек с картошкой в духовке
Ср 12.06.2024
Сырники "По-Бабушкиному"
Почему так много людей ненавидит свою работу и что с этим можно сделать Ср 12.06.2024
Почему так много людей ненавидит свою работу и что с этим можно сделать
15 лёгких рецептов подливы для картофельного пюре Сб 08.06.2024
15 лёгких рецептов подливы для картофельного пюре
Выбираем лучший интегральный усилитель 2023-2024 годов Ср 05.06.2024
Выбираем лучший интегральный усилитель 2023-2024 годов
Нагрузочное тестирование: что? где? когда? Пн 03.06.2024
Нагрузочное тестирование: что? где? когда?
15 лёгких рецептов свиных рёбрышек в соевом соусе Сб 01.06.2024
15 лёгких рецептов свиных рёбрышек в соевом соусе
Understanding color schemes & choosing colors for your website Ср 29.05.2024
Understanding color schemes & choosing colors for your website
Для чего нужна «умная» колонка и какую выбрать Ср 29.05.2024
Для чего нужна «умная» колонка и какую выбрать
Книги
Blazor in Action Вт 04.06.2024
Blazor in Action
Год: 2022
Security for Containers and Kubernetes Вт 28.05.2024
Security for Containers and Kubernetes
Год: 2023
Designing Data-Intensive Applications Вт 14.05.2024
Designing Data-Intensive Applications
Год: 2017
Fundamentals of Software Architecture Вт 07.05.2024
Fundamentals of Software Architecture
Год: 2020

Разработано на основе BlackNight CMS
Release v.2024-06-16
© 2000–2024 Blackball
Дизайн & программирование:
О сайтеРеклама
Visitors
Web-site performed by Sergey Drozdov
BlackballРекламаСтатистикаПоддержка | МузыкаПлейлистыКиноВидеоИгрыАудиоПрограммыСтатьиКартинкиЮморФорумДневник сайтаПрислать контент