Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>16 июн 2021</li>

3 <li>0</li>

4 </ul><h2>Технический долг: что это такое и как с ним жить</h2>

5 Быть или не быть регулярному рефакторингу? Мы попытались разобраться с этой холиварной темой - не без помощи людей, которые знают врага в лицо.

6 Журналист, коммерческий автор и редактор. Пишет про IT, цифровой маркетинг и бизнес. Сайт:<a>darovska.com</a>.

7 Технический долг - это модули, написанные на старых фреймворках, "костыли", мелкие недоработки, нарушенные стандарты и прочий мусор в коде, который в будущем усложняет жизнь. То самое чувство, когда читаешь код и думаешь: "Ну что за нехороший человек это всё писал". А потом оказывается, что этот "редиска" - ты сам из прошлого. Сам термин - метафора пионера паттернов и изобретателя технологии Wiki<a>Уорда Каннингема</a>.

8 Недоработки постоянно накапливаются. Чем их больше, тем сложнее добавить в код новую классную функцию. Необходимые усилия, которые придётся приложить в будущем, - как проценты по кредиту. Расплаты всё равно не избежать, а долг со временем всё растёт и растёт.

9 Согласно<a>исследованию</a>Stripe, разработчики тратят на технический долг треть своего времени, а компании "сливают" на это примерно 85 млрд долларов ежегодно. Быстро вывести на рынок жизнеспособный продукт, приносящий пользу бизнесу, - неплохое решение. Но надо помнить, что технический долг рано или поздно начнёт вредить проекту.

10 "Нельзя прийти и создать сразу идеальный проект. Каждый день мы будем что-то узнавать о предметной области, и эти новые знания нужно сразу внедрять. Вначале это будут костыли, из которых копится технический долг, - и это нормально. Ведь мы не можем, получая новую информацию, каждый раз переписывать продукт заново. Бизнес нас не поймёт".

11 Алексей Некрасов, лидер направления Python в МТС, программный директор направления Python в Skillbox

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

13 Пример №1

14 Канадская компания<a>разработала</a>хороший продукт для местных клиентов и решила повторить успех, расширив рынок сбыта на ту часть страны, где говорят в основном по-французски. Разработчики управились за неделю, добавив кучу if-then-else. Решение с оператором условий было быстрым и грязным, но на тот момент - оправданным. Продукт смог заработать ещё денег.

15 Месяц спустя в Японии фаундер похвастался, что поддержку японского они могут добавить за неделю. Но одно дело - по-быстрому накодить один дополнительный язык, и совсем другое - добавлять так же криво все последующие. Тем более что для японского решение с новым слоем if-then-else вообще не подходило - мешали иероглифы, да и текст японцы пишут вертикально. В итоге разработчикам пришлось писать нормальную систему локализации.

16 Пример №2

17 Разработчики написали<a>приложение</a>на устаревших версиях Python, PHP и Java с жёсткой структурой из бесконечных операторов if. В какой-то момент они решили полностью переписать ядро на свежих версиях языков, но на каждом шагу объёмы работы возрастали - постоянно обнаруживались какие-то новые зависимости. Да и бизнес не хотел ждать - требовал новые функции, чтобы оставаться конкурентоспособным. В итоге за год рефакторинга команда практически не продвинулась вперёд.

18 Американский программист, автор книг и статей по архитектуре ПО <a>Мартин Фаулер</a>определял размер техдолга простой формулой: чем больше усилий программистов тратится на какой-то недоработанный в прошлом фрагмент кода, тем больше наш технический долг. При этом консультант по разработке ПО Роберт Мартин<a>считает</a>, что технический долг в прототипах и краткосрочных проектах можно и нужно игнорировать.

19 Есть разные классификации технического долга.

20 Например, CTO производителя весов для угарного газа Tapad Даг Лиодден выделяет<a>три его типа</a>:

21 <ul><li>Умышленный. Когда долг берётся, чтобы быстрее выпустить продукт. Его необходимо отслеживать в бэклоге и регулярно отдавать - иначе велик риск никогда его не вернуть.</li>

22 <li>Случайно взятыйдолг или устаревший код. Чтобы вовремя его выявить, необходимо регулярно проводить аудит. Такой тип долга возникает из-за плохой коммуникации внутри компании.</li>

23 <li>Критичный. Самый опасный тип долга - откровенно плохой и некачественный код. Его надо исправлять в первую очередь.</li>

24 </ul>Как правило, самый неприятный техдолг связан с архитектурными проблемами: отсутствием инкапсуляции и модульности, плохим применением шаблонов, несоответствием типов данных модели данных. Из-за этого тормозится разработка, трудно вносить изменения в код, исправлять ошибки. Такой долг трудно или вообще невозможно обнаружить инструментами вроде IDE, PMD или Checkstyle.

25 Чтобы понять, как победить техдолг, нужно тщательно его проанализировать.

26 <ol><li>Оцените опасность технического долга - в этом помогут<a>рекомендации</a>спикеров конференции GOTO Berlin 2017. Прикиньте, сколько усилий приходится тратить на его поддержку: как часто меняется конкретный файл, насколько сложен и объёмен код. Уберите из этого списка простые проблемы вроде неиспользуемого импортированного кода. Обычно их легко обнаружить с помощью специальных инструментов - того же<a>SonarQube</a>.</li>

27 <li>Приоритизируйте работы над опасным техдолгом (оставшийся после первого шага список),<a>определите</a>и оцените зависимости между масштабами изменений: бизнес-ценность компонентов с долгом, историю, возраст и планы на блоки кода, вероятность того, что техдолг именно в этом месте будет вредить. Например, бессмысленно сразу исправлять проблемы, которые обнаружились в дублированных блоках кода, - сначала нужно устранить причину их появления, бездумную "копипасту". Также не стоит рефакторить непопулярную и устаревшую фичу, которую наверняка уберут из продукта.</li>

28 </ol>Владельцам софта нужна прибыль, поэтому они не хотят затягивать процесс разработки и бороться с техдолгом - особенно если близок старт продаж. Однако долг всегда приходится возвращать - иначе он создаёт проблемы в будущем продукте.

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

30 Вообще, Уорд Каннингем придумал концепцию техдолга именно для того, чтобы в понятных для бизнеса терминах аргументировать необходимость рефакторинга. Метафора простая:первая версия программы - как заём в банке. А каждая минута, которая тратится на исправление "костылей" в коде, - как проценты по кредиту. Если проценты долго не гасить, банк истребует весь долг и компания может закрыться. Однако небольшой долг, как и разумно взятый кредит, ускоряет разработку и помогает расти, главное - выплачивать его вовремя.

31 "Представьте платформу для нескольких независимых друг от друга клиентов (из терминологии "клиент - сервер". - Прим. ред.). У каждого есть собственный сервис, весьма требовательный к аппаратным ресурсам. Пока клиентов мало, эта схема работает. Когда же количество клиентов резко увеличивается, возникает необходимость менять архитектуру и запускать один сервис, который будет обслуживать всех, вместо нескольких копий, работающих параллельно. А это уже экономия в чистом виде и вполне убедительный аргумент для бизнеса.

32 Пока критической ситуации не возникло, многие воспринимают технический долг как нечто абстрактное. К сожалению, часто осознание приходит, только когда бизнес теряет деньги или несёт репутационные потери. Но после этого он сразу понимает важность рефакторинга".

33 Николай Мельников, руководитель компании<a>Sebbia</a>

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

35 "У нас в BestDoctor есть договорённость, что один день в неделю каждый программист выделяет на работу с техническим долгом и автоматизацию, которая улучшает жизнь всей команде разработки. Этот день полностью посвящён не продуктовым, а инженерным задачам. Я рекомендую ввести обязательный процесс отдачи технического долга раз в неделю или раз в две недели. Это позволит не запускать его".

36 Михаил Корнеев, тимлид в BestDoctor, автор YouTube-канала "<a>Хитрый питон</a>"

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

38 "Если уже сложилась ситуация, когда надо немедленно реагировать и что-то делать с техдолгом, значит, что-то не так с процессами. Нужно сразу планировать работу так, чтобы оставалось время на рефакторинг - от 5% до 33% рабочей недели. Команда должна знать, что у неё есть выделенное время для таких задач".

39 Николай Мельников, руководитель компании<a>Sebbia</a>

40 <ul><li>Соблюдать баланс между размером техдолга и скоростью разработки.</li>

41 <li>Стараться писать максимально качественный код.</li>

42 <li>Регулярно проводить аудит и ревью кода.</li>

43 <li>Включить рефакторинг в план работы на регулярной основе.</li>

44 <li>Объяснять бизнесу, как технический долг сказывается на экономике продукта.</li>

45 <li>Оперативно ликвидировать наиболее критические моменты технического долга.</li>

46 <li>Вовремя обновлять инструменты, фреймворки и библиотеки.</li>

47 <li>Регулярно обновлять документацию, фиксировать все изменения.</li>

48 <li>Тщательно тестировать код.</li>

49 </ul>Хотите изучить новый язык программирования или неизвестный фреймворк? Выбирайте подходящий среди<a>курсов Skillbox</a>.

50 <a>Бесплатный курс по Python ➞Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу</a>