Технический долг IT-продукта: причины, как им управлять и что делать, когда он уже накопился

Замечаете, что внедрение нового функционала занимает все больше времени, а пользователи жалуются на баги? Уже сменили несколько команд программистов, но ситуация не улучшилась? Все это частые последствия технического долга на проекте. Ведь бизнес сосредоточен на развитии продукта и далеко не всегда вникает в технические тонкости.

Мы — SVK.Digital — больше 25 лет разрабатываем IT-продукты и видели разные кейсы. В этой статье постараемся на пальцах объяснить бизнесу, что такое технический долг, почему его необходимо своевременно закрывать, и как решить проблему, если он уже накопился.

Технический долг означает накопленные в программном коде или архитектуре проблемы. Это может быть:

Коварство технического долга в том, что он как хроническое заболевание. Вы можете с ним жить годами. Да, что-то будет беспокоить, но не настолько, чтобы лечиться. Кажется, что все хорошо, но проблемы медленно, но верно копятся. И лет через 5, в какой-то момент, может отказать больной орган и поставить под угрозу жизнь человека.

Так и с техдолгом. Можно годами с ним ничего не делать, будут просто симптомы, например, больше багов, дольше релизы. Но в какой-то момент разработка остановится и каждая малейшая задача будет решаться месяцами. Будет уже поздно проводить обслуживание техдолга, придется переписывать проект и вкладывать сразу огромные ресурсы. Начнутся еще проблемы с наймом, так как мало кто хочет из программистов ковыряться в «грязном» коде, придется за это переплачивать.

Например, к нам пришел на аудит бизнес, который 13 лет создавал проект для медицины и, естественно, там невероятный техдолг и любое простое изменение добавляется месяцами. Но почему же разработчики, которые годами создавали этот продукт, вовремя не обслуживали техдолг?

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

Чтобы была инициатива от разработчиков, нужна сильная команда, которая имеет авторитет перед бизнесом. Если авторитета нет, то бизнес будет постоянно откладывать обслуживание техдолга в долгий ящик пока не станет поздно. Ведь бизнес видит эту задачу как деньги и время на ветер, так как не появляется ни новых функций продукта, ни новых разделов. Обычно, выделяют деньги на обслуживание технического долга, когда неприятные симптомы уже проявились.

Какими бы крутыми не были программисты, проект развивается, меняются требования, и старые решения перестают работать. Это естественный процесс.

Например, мы построили одноэтажный небольшой дом, нам в нем комфортно жить одному. С появлением жены и детей уже появляется необходимость в трехэтажном доме. Если мы не укрепим фундамент и просто пристроим еще 2 этажа, то он посыпется.

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

Накопление техдолга зависит не от времени, а от скорости разработки.

Можно разработать продукт, покрыть код тестами, 10 лет ничего не добавлять и техдолга не будет. Проект будет работать 10-12 лет даже без обслуживания. Но если вы захотите добавить новые функции спустя 12 лет, то проще будет переписать проект с нуля на современных фреймворках, чем искать программистов на устаревшие версии языка.

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

Нужно оценить, какой способ быстрее и менее рискованно приведет к тому состоянию проекта, к которому вы хотите прийти. Таких способов три:

1. Постепенное устранение техдолга (рефакторинг)

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

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

Вывод: чем дольше не делался рефакторинг, тем выгоднее и быстрее переписать продукт с нуля. Поэтому закладывайте до 20-25% от времени разработки на обслуживание кода, пока еще нет симптомов техдолга. Это позволит сохранить высокие темпы релизов и продлить срок жизни проекта.

2. Полная модернизация (переписывание с нуля)

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

Это все равно что рядом с домом построить новый такой же дом, а потом поменять их местами, пытаясь не потерять содержимое нового. В маленьких, простых сайтах и приложениях это возможно.

В крупных проектах половина все равно потеряется, то есть будет много багов. И если для вашего бизнеса IT-продукт — важный элемент, c которого вы получаете прибыль, например, у вас интернет-магазин, то слишком высокий риск, что бизнес понесет большой урон от таких замен. В больших проектах процесс может затянуться на годы и сопряжен с многочисленными рисками для бизнеса. Потому что когда вы развивали проект лет 10, то создать его заново возможно лет за 7, не меньше.

Например, наш клиент с сайтом на Bitrix, которому 20 лет, вложил 100 млн рублей, чтобы построить такой же сайт только на новых технологиях. Но до сих пор еще не догнал старый сайт по функционалу. И получается у бизнеса один недоделанный сайт, а другой — переделанный с техдолгом.

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

3. Постепенная (лоскутная) модернизация кодовой базы

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

Это тоже самое переписывание с нуля, вы также делаете новый сайт рядом со своим действующим, но новые страницы и разделы постепенно интегрируете в старый сайт. Пользователь даже не заметит, что переключаясь между страницами, он переключается между новым и старым сайтом.

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

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

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

Технический долг – это неизбежная часть разработки и развития IT-продуктов, но не нужно допускать, чтобы он копился. Должен быть процесс управления техдолгом. Выделяйте до 20-25% от времени разработки на рефакторинг даже на свежем проекте.

Если решили переписывать с нуля, то для больших проектов выбирайте постепенную (лоскутную) модернизацию. Она позволяет минимизировать риски и обеспечить плавный переход на новые технологии.

Если вы не знаете, в каком состоянии код вашего продукта, стоит ли продолжать вкладывать деньги, можно ли обойтись рефакторингом или уже пора переписывать продукт с нуля? Пишите, мы проведем аудит кода, составим подробный отчет о проблемах и дадим рекомендации, что делать дальше, чтобы успешно развивать IT-продукт!