Настя Котова // Frontend & Node.js

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

Да, доклад назывался «Не переписывай — обнови», и я действительно продвигаю эту идею. Но и сама не раз попадала в ситуации, когда обновление невозможно. Чаще всего это касается старых проектов, написанных не на чём-то из «большой тройки» (React, Angular, Vue). В таких случаях зачастую просто не остаётся другого выхода, кроме как переписывать всё заново.

Если проект построен на кастомном фреймворке или устаревшем решении, то он обречён на тяжёлую поддержку: современные библиотеки не интегрируются или делают это через боль, разработчики стараются обходить такие задачи стороной (типичная оценка «10 sp за простой баг» и привет вечный бэклог), а ещё продать такой проект при найме будет крайне сложно.

Совсем другое дело, если проект написан на React, пусть даже на версиях 16 или 17. Здесь ключевое преимущество в том, что обновление не требует перестраивать архитектуру и саму идеологию кода: как были компоненты — так они и остаются. Да, классовые, но это те же самые компоненты, которые можно переписывать и переносить постепенно, параллельно занимаясь и продуктовыми задачами.

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

Вопрос, который мне задали на докладе, оказался очень в точку: что делать, если проект стареет быстрее, чем вы его обновляете? Тут важно определить для себя критерии «легаси». Например, если у вас библиотека пятой версии, а недавно вышла шестая — это не значит, что проект мгновенно стал легаси. Но если версия 5 уже три года официально считается устаревшей и реально мешает работе (замедляет сборку или использует подходы, которые давно вышли из употребления, как это было с классами против функциональных компонентов), вот тогда пора действовать.

И напоследок. Если у вас всё же тот самый первый вариант, когда переписывать приходится с нуля, продумайте стратегию постепенного перехода. На одном из проектов мы буквально переписывали его «по страницам». Да, и это проходило не без проблем, но так задачу можно было декомпозировать и оценивать. Параллельно брали продуктовые истории — иногда в новые страницы, иногда даже в старые (компромиссы неизбежны).

Никто не согласится на план «нам нужен год, никакие фичи не делаем, и не факт, что даже уложимся». Любое обновление должно быть разбито на понятные этапы. Так и прогресс виден: не как мифические «0 и вдруг 100%», а постепенно, по шагам. И для команды, и для менеджмента это куда легче и понятнее.

❤8🔥4👍1😁1

www.tgoop.com/startpoint_dev/170

806 viewsAug 11 at 15:25

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

Да, доклад назывался «Не переписывай — обнови», и я действительно продвигаю эту идею. Но и сама не раз попадала в ситуации, когда обновление невозможно. Чаще всего это касается старых проектов, написанных не на чём-то из «большой тройки» (React, Angular, Vue). В таких случаях зачастую просто не остаётся другого выхода, кроме как переписывать всё заново.

Если проект построен на кастомном фреймворке или устаревшем решении, то он обречён на тяжёлую поддержку: современные библиотеки не интегрируются или делают это через боль, разработчики стараются обходить такие задачи стороной (типичная оценка «10 sp за простой баг» и привет вечный бэклог), а ещё продать такой проект при найме будет крайне сложно.

Совсем другое дело, если проект написан на React, пусть даже на версиях 16 или 17. Здесь ключевое преимущество в том, что обновление не требует перестраивать архитектуру и саму идеологию кода: как были компоненты — так они и остаются. Да, классовые, но это те же самые компоненты, которые можно переписывать и переносить постепенно, параллельно занимаясь и продуктовыми задачами.

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

Вопрос, который мне задали на докладе, оказался очень в точку: что делать, если проект стареет быстрее, чем вы его обновляете? Тут важно определить для себя критерии «легаси». Например, если у вас библиотека пятой версии, а недавно вышла шестая — это не значит, что проект мгновенно стал легаси. Но если версия 5 уже три года официально считается устаревшей и реально мешает работе (замедляет сборку или использует подходы, которые давно вышли из употребления, как это было с классами против функциональных компонентов), вот тогда пора действовать.

И напоследок. Если у вас всё же тот самый первый вариант, когда переписывать приходится с нуля, продумайте стратегию постепенного перехода. На одном из проектов мы буквально переписывали его «по страницам». Да, и это проходило не без проблем, но так задачу можно было декомпозировать и оценивать. Параллельно брали продуктовые истории — иногда в новые страницы, иногда даже в старые (компромиссы неизбежны).

Никто не согласится на план «нам нужен год, никакие фичи не делаем, и не факт, что даже уложимся». Любое обновление должно быть разбито на понятные этапы. Так и прогресс виден: не как мифические «0 и вдруг 100%», а постепенно, по шагам. И для команды, и для менеджмента это куда легче и понятнее.

BY Настя Котова // Frontend & Node.js