Как меняется взгляд на легаси после смены нескольких проектов
Раньше мне казалось, что легаси это показатель того, что команда когда-то приняла плохие решения. Открываешь проект и сразу возникают мысли: Почему никто не перепишет этот участок? Тогда казалось, что если использовать современные технологии и сразу строить хорошую архитектуру, то таких проблем получится избежать. Но за несколько проектов мой взгляд сильно изменился. Моим первым большим проектом была система на jQuery, PHP и CSS. В какой-то момент мне поставили задачу изучить React и начать переписывать проект. Для меня, как для джуна, это было очень круто. Казалось, что сейчас мы постепенно избавимся от старого кода и сделаем современное приложение. Но через какое-то время стало понятно, что полностью переписать проект мы просто не сможем. Потому что бизнесу нужно было развивать продукт. Переписывание не приносило новых клиентов и не решало задачи бизнеса здесь и сейчас. В итоге от идеи полного переписывания отказались. Позже я сделал редизайн системы, появились дополнительные аргументы, и нам дали возможность внедрить Vue. Но даже тогда никто не начинал всё с нуля. Мы просто начали постепенно строить новую систему поверх старой. Если честно, тогда меня это немного расстраивало. Хотелось всё переписать.
Параллельно я изучал React, Vue и Angular на своих пет-проектах. Казалось, что вот теперь-то я понимаю, как нужно делать правильно.
Потом был второй проект. Снова старый Vue. Снова легаси. И снова команда прекрасно понимала, что обновляться нужно. Но переписать всё за один раз было невозможно. Постепенно мы переносили части системы на новую версию Vue. Где-то продолжали поддерживать старую реализацию, потому что переписывание не давало ощутимой пользы бизнесу. Этот процесс занял несколько лет. И, насколько я знаю, продолжается до сих пор.
Тогда я впервые понял. Иногда команда оставляет легаси не потому, что ей всё равно. А потому что это самое рациональное решение на текущий момент.
Сейчас я работаю уже на третьем проекте. И здесь тоже есть легаси. Когда только начал погружаться в проект, снова возникло желание многое поправить. Но в этот раз оно довольно быстро прошло. И очень часто ответ оказывается довольно логичным. Где-то не хватило времени. Где-то изменилась логика продукта. Где-то переписывание оказалось слишком дорогим. А где-то этот код просто работает, и никто не готов тратить несколько недель на его замену, если для пользователя ничего не изменится.
Конечно, плохой код существует. И далеко не любое легаси можно оправдать. Но после нескольких проектов я перестал воспринимать его как показатель слабой команды. Скорее наоборот. Чем дольше живет продукт, тем больше в нем появляется таких мест. И это нормально. Самое интересное, что раньше мне казалось: стоит один раз перейти на современный стек, сделать хорошую архитектуру и проблема исчезнет.
Сейчас я понимаю, что это не так.
Любая новая архитектура со временем тоже начинает обрастать компромиссами. Появляются новые требования. Меняются технологии. Меняется команда.
Что-то откладывается на потом” Что то делается быстро, потому что бизнесу нужно выпустить новую функциональность. И постепенно тот код, который сегодня кажется современным, через несколько лет тоже станет легаси. Наверное, именно это сильнее всего изменило мой взгляд.
Я не стал любить легаси. Я просто перестал считать, что оно всегда появляется из-за плохих разработчиков. Чаще всего это следствие того, что продукт живет, развивается и меняется. И, скорее всего, через несколько лет кто-то будет открывать код, который мы пишем сегодня, и думать:
“Интересно, почему они сделали именно так?”