Допустим, у нас есть проект / продукт, который живёт 3-4 года. Это большой срок. Скорее всего, требования несколько раз заметно изменились. Технические и архитектурные решения, которые закладывались на старте разработки, оказались не то, чтобы неудачными, но, откровенно, уже мешают.
❓Перед разработчиками встаёт вопрос: «А что делать-то в такой ситуации?» Откатываться на несколько лет разработки назад и начинать всё заново? Вы серьёзно? А бизнес что скажет? Опытные разработчики понимают, какой это больной удар для бизнеса и не будут предлагать всё переписывать с нуля.
Можно решить облепить костылями старый функционал, чтобы обеспечить его совместимость с новыми требованиями. Не понимаете, о чём речь? Опытные разработчики применяют паттерн «адаптер», чтобы иметь возможность на существующей кодовой базе удовлетворять новым требованиям, предсказать существование которых на этапе начального проектирования было невозможно. Даже если какой-то умный человек заранее заложил модульную архитектуру либо использовал микросервисы, то это не спасёт от адаптационного слоя, но ограничит масштабы бедствия модулем или сервисом.
⚠️Юмор ситуации в том, что требования могут снова поменяться и потребуется ещё один адаптационный слой функционала, затем ещё один. В один момент во всех этих костылях становится очень сложно разобраться, и вся конструкция рушится. Простым языком — усталость кода и размеры технического долга вырастают настолько, что скорость разработки нового функционала существенно падает на фоне резкого увеличения регресса системы, после внесения изменений. Наступает технический дефолт . То есть техническая команда не может погасить проценты по техническому долгу.
Именно в такой ситуации родилась шутка.
Ну, представь, что ты писатель и поддерживаешь проект «Война и мир». У тебя ТЗ — написать главу, как Наташа Ростова гуляла под дождём по парку. Ты пишешь: «шёл дождь». Сохраняешь. Вылетает сообщение об ошибке: «Наташа Ростова умерла, продолжение невозможно». Почему умерла? Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли. Он упал. Его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение: «Поручик Ржевский умер». Выясняется, что он в следующей главе облокачивается о столб, которого уже нет... Система становится слишком сложной и непредсказуемой.
❌Для тех, кто излишне верит в рефакторинг, можем сразу сказать, что он не поможет. Рефакторингом исправить архитектурные проблемы не получится, а именно они будут источником большей части проблем. Именно здесь начинается долго, непредсказуемо, много ошибок, очень сложно и так далее, что может напоминать JSDD. Только всё это будет не видимостью, а на самом деле с реально выгоревшими разработчиками.
Дальше появляются новые герои — золотые шестерёнки. Знакомству с ними посвящена следующая статья.