Будучи ведущим инженером, я неоднократно наблюдал следующую картину в разных компаниях.

1. Руководители жалуются на недостаточно высокую скорость разработки. "Я просто хочу показывать день рождения пользователя на странице настроек. Почему на это уходит целый год?"
2. Инженеры говорят, что техдолг мешает им двигаться вперед.
3. Руководство поручает менеджерам «разобраться с техдолгом», чтобы повысить скорость разработки.
4. Менеджеры начинают искать крупные проекты с технологическим долгом, чтобы добавить их в роадмап
5. Амбициозный разработчик продвигает масштабный привлекательный проект, над которым интересно работать, который красиво смотрится в резюме и/или поможет получить повышение. «Перейдём на событийную архитектуру! И на сей раз — по-настоящему правильно!»
6. Менеджеру нравится это, потому что такой проект для него престижен, хорошо смотрится в резюме и показывает, что он активно «повышает скорость разработки».
7. Руководство понятия не имеет о том, как устроена текущая система, не говоря уже о предлагаемой событийно-ориентированной архитектуре. Но она им нравится, потому что обещает решение их главной проблемы. «В будущем все запросы на разработку новых фич будут выполняться за считанные дни!»
8. Половину инженерной команды перебрасывают на «Грандиозный Проект по Устранению Техдолга» на следующие несколько кварталов. За это время будут внесены минимальные улучшения, почти не заметные для пользователей
9. Год спустя проект завершается. Все празднуют. Людей повышают в должности.
10. Скорость разработки теперь чуть выше. Но процесс по-прежнему упирается в десятки нерешенных проблем.
11. Новый техдолг начинает копиться в свежей системе сразу после первого же запроса на новую функцию.

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

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

• Некачественные тесты, из-за которых приходится тратить время на отладку, решая мнимые проблемы. Из-за этого замедляется развертывание CI/CD.
• Бреши в тестовом покрытии, из-за которых разработчики тратят часы на ручное тестирование каждого изменения.
• Плохая документация, из-за чего люди тратят 30 минут на выполнение задачи, которая должна занимать 1 минуту.
• Функции на 200 строк и классы на 3000 строк с ужасно поименованными переменными и методами — настоящий кошмар, так как в коде ничего не понятно, а с ним приходится работать.
• Запутанные объектно-ориентированные иерархии с избыточными абстракциями и неожиданными побочными эффектами — приходится потратить целый день, чтобы просто понять эту мешанину перед внесением изменений.

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

Невозможно решить проблему неработающих тестов, слишком сложного кода и плохой документации с помощью большого проекта роадмапа. Просто слишком много мелких препятствий, разбросанных по разным уголкам. Попытка перечислить их все, отнести к DRI, привязать к тикетам спринт-планирования или OKR, отследить их выполнение… всё это займет столько же времени, сколько и сама работа. Хуже того: такой формализованный «водопадный» процесс даже не позволяет выявить большинство проблем.

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

• Призывайте команду находить время на совершенствование кода вместо того, чтобы просто сдавать изменения как можно быстрее.
• Создайте культуру код-ревью, в которой уделяется особое внимание сложности, удобочитаемости кода, документации и тестированию.
• Считайте код-ревью неотъемлемой обязанностью сотрудников. Подходите к этому как к инструменту, с помощью которого сеньор-разработчики направляют команду и поддерживают техническое качество проектов… и соответствующим образом планируйте под это время. Не стоит просто сбрасывать проверки джуниор-разработчикам для формального 'одобрения'.
• Поощряйте и давайте возможность каждому сотруднику исправлять мелкие проблемы, которые он замечает при повседневной работе. Не топчите эти мелочи в бюрократии спринт-планирования. Не должно быть так, что для добавления документации нужно создавать JIRA-тикет, ждать его обсуждения и приоритезации. «Увидел проблему — реши проблему».
• Дайте понять вашим старшим и ведущим инженерам, что их главная обязанность — не только работать над масштабными «глянцевыми» проектами, но и обеспечивать прогресс всей команды. Они должны регулярно выделять время на выявление и устранение всего, что создаёт технический долг или тормозит коллег — даже если это рутинная, неприглядная работа вроде рефакторинга сложной функции или дописывания неполной документации.
• Признавайте и поощряйте вклад инженеров в ежедневную работу по улучшению кода и сокращению техдолга. Особенно отмечайте заслуги senior-разработчиков, чьё руководство приводит к отличным результатам всей команды — даже если лично они не реализовали ни одного «эффектного» проекта.

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

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

P.S. Обращаем ваше внимание на то, что у нас на сайте проходит распродажа.