Легаси: казнить нельзя помиловать? ⚖️

К нам часто обращаются с “легаси" проектами. Мне кажется что за долгие годы мы научились с этим работать и сформировали умение — пожалуй, это то, что мы делаем неплохо: берем чужой код, разбираемся в нем, рефакторим, формируем дорожную карту и продолжаем развивать проект.

Самый частый сценарий, с которым к нам приходят, звучит так: "У нас есть существующий проект. Там много проблем, которые мы не хотим или не можем решить — либо наш текущий подрядчик не справляется. Поэтому мы хотим все переделать с нуля. Чтобы было как раньше, только лучше. И без легаси." 🔄

Но вот в чем загвоздка — это почти никогда не работает так, как задумано.

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

Спойлер: в большинстве случаев — нет, не настолько плохо. ⚠️

На мой взгляд, существует довольно много ситуаций, когда лучше развивать существующий легаси-проект, чем начинать разработку с нуля. Когда код становится легаси?⏳ Вот вопрос: в какой момент проект или код становится "легаси"? Через год? Месяц? День? Может, час после релиза? Вопрос, на самом деле, открытый.

Но суть даже не в этом. Как правило, такие "старые" системы — это большие проекты с множеством связей и интеграций с внешними сервисами. И именно в этих связях и скрывается "мякотка" 🕸 проекта.

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

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

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

Проект новый, проблемы старые 🚧 И вот вы делаете новую систему. Новую, красивую, "без легаси". Запускаете, и... начинается: всплывает айсберг незадокументированных, неочевидных проблем, которые снова приходится решать.

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

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

Так зачем тогда? 🤔 Получается странная картина. С одной стороны, есть старый проект с накопленными проблемами. С другой — новый, который тоже начнет обрастать своими. И если учесть, что многие старые "ужасы" можно спокойно решить и в текущем проекте, возникает вопрос: а зачем все это начинать с нуля?

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

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

Но важно помнить: легаси бывает разным. Есть разница между десятилетним проектом на PHP 5.6 и двухлетним на Laravel. Подход "всех под одну гребенку" здесь не работает.

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