Как стать автором
Обновить

Комментарии 9

Если проект не просто legacy, а еще и постоянно кем-то изменяется, то для psalm очень удобно использовать baseline. Сначала создаем baseline для старого кода, все новые изменения уже получат проверку, при этом не надо дожидаться фиксов для старого кода.

На нашем legacy проекте использовали кодогенератоы. Например для создания тех же DTO из старых legacy массивов. Парсим старый код, пытаемся понять из него, что будет возвращаться, генерируем DTO, подменяем вывод на новый DTO в исходнике старого скрипта. Срабатывает не для всех проектов, но когда срабатывает, то делает это очень эффективно и быстро.

Неиспользуемый код довольно легко вычисляется небольшим обработчиком событий на проде, который на каждый запрос оставит в логах (в нашем случае был ELK) запись какой именно эндпоинт был запрошен. Дальше просто сравниваем это со swagger, например. После того как все живые эндпоинты покрыли тестами, можно по coverage вычислить неиспользуемые сервисы, модели и т.д.
На мой взгляд в статье можно добавить ещё один шаг:
Пятый шаг. Введение стандартов разработки. После того, как вам удалось привести код в порядок необходимо «закрепить» наработки в виде каких-либо внутренних правил, стандартов для разработчиков. Если у вас уже имеется успешный опыт улучшения легаси конкретно в вашей команде, а в других командах продолжают работать «по старинке», то рано или поздно в коде появятся всё те же проблемы с которыми вы успешно поборолись. Другими словами, если конкретно вам удалось вытянуть проект и далее поддерживать его, то все это развалится после вашего ухода (повышение или переход в другую компанию).

Да, кстати, отличный поинт! Спасибо!

Лично у меня в команде такая работа проводится с помощью ручками написанного линтера. Он стоит как локально, так и на CI/CD система. Когда я только пришел, он очень выручил в плане того, что в итоге старая и новая кодовая база написана в едином стиле

Хотел написать про TDD. А потом как-то увял и пошёл домой.
Но вы открываете IDЕ, делаете пул репозитория с проектом — и хочется плакать.


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

То есть, доходите до такого состояния возвышенности, при котором разгребать и рефакторить ваше — нужно звать кого-то другого?


Вы не сочтите это за персональный выпад, я просто (как профессиональный разгребатель, ага) очень порядочно повидал людей, которые слишком крутые и офигенные профессионалы, чтоб чё-то там рефакторить (во всяком случае, по их личному мнению).

Зачем вы ее туда вставляли..

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.