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

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

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

Техдолг проще всего понять на аналогии с ремонтом.

Вы въезжаете в квартиру и быстро ставите проводку там, где удобно сейчас, не выравниваете стены, тянете удлинители. Кажется, что жить можно! Но с каждым месяцем передвинуть розетки и вообще что-то поменять становится дороже, удлинители наращиваются удлинителями, и в итоге нужен не мелкий ремонт, а капитальный, который в разы сложнее и дороже.

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

Иногда это оправданная плата за выпуск релиза в срок или проверку гипотезы. Но если техдолг не выплачивать, то код превращается в лабиринт, где каждое изменение стоит бизнесу огромных денег и времени.

Отдельным видом техдолга является легаси-код (от англ. legacy — наследство).

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

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

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

Скорость и стабильность работы проекта

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

Код и архитектура

• Нарушен базовый принцип DRY (Don’t Repeat Yourself — «Не повторяйся»): одна и та же логика дублируется в десятках мест. Изменение требует правки всех копий.
• Появляются «божественные объекты» (God Object) и «спагетти-код» — огромные модули или функции на сотни строк, которые знают и делают слишком много.
• Код сложно читать даже его авторам. В нём используются «магические числа» (например, if (user.status == 5)), смысл которых никто не помнит.
• Команда боится трогать определённые части системы. Никто не уверен, как они работают и что от них зависит. Это святыни, и за стабильность их работы остаётся только помолиться.

Работа команды

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