Как принимать архитектурные решения при рефакторинге backend'a legacy-проекта

Сеть, бэкенд и web-разработка

Бэкенд / другое
Методы и техника разработки ПО
Legacy системы, жизненный цикл продуктов
Поддержка и развитие legacy систем

Доклад принят в программу конференции

Целевая аудитория

Senior backend-разработчики, архитекторы.

Тезисы

Классическая история: пытаетесь распилить бэк на микросервисы, а на выходе получается все тот же монолит, только распределенный, который все так же сложно поддерживать. ИЛИ. Начали рефакторинг, и только на середине стало понятно, что надо было делать по-другому.

Можно ли снизить риск переделок или хотя бы уменьшить затраты сил и времени на них? Можно.

Доклад — небольшая часть масштабного исследования, которое я веду с 2017 года. Разобрал за это время более 500 проектов и решений, около 20 из которых — мой личный опыт как full time-программиста и проектировщика.

Из доклада вы узнаете:
* как подходить к масштабному рефакторингу бэкенда, чтобы не запроектировать себя в угол;
* с какими трудностями вы столкнетесь в процессе;
* упростить внедрение новых фич, когда новая архитектура доедет до прода.

Роман Зайруллин

Независимый исследователь

Backend-разработчик, консультант, независимый исследователь.

Независимый исследователь

В данный момент вместе с исследовательской группой разрабатывают продукто-антагонистичные (не связанные с конкретными ЯП, БД, фреймворками и т.д.) методы описания решения задач разработки. Как независимый консультант помогает с планированием изменений и перестройкой архитектуры legacy-софта (преимущественно web).

Видео