Как работать с legacy-проектами: проблемы и стратегии решений

Многие из нас предпочли бы всегда делать проекты с чистого листа, создавать что-то новое, современное и правильное сразу. Однако реальность часто заставляет нас сталкиваться с наследием прошлых разработчиков, с чем связано немало трудностей.

Недавно на конференции "Стачка" СТО Articul, Борис Кузьмин, делился опытом работы с такими проектами. Эта статья представляет собой краткое изложение его выступления, где мы рассмотрим пять основных проблем с легаси и предложим способы их решения из опыта технического директора.

Время идет, системы растут и развиваются, а от коллег мы продолжаем слышать: «Пришел на проект, а тут никакой документации, смотрим в код». Ее отсутствие сильно увеличивает время на погружение и затраты на исследование новой командой.

Только тесное взаимодействие с product owner и/или ЛПР поможет компенсировать этот недостаток. Нужно найти этого человека в команде заказчика, адресовать ему вопросы и вовлечь аналитиков для создания или обновления документации.

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

Что необходимо: акцентировать внимание клиентов на значимости использования собственных ресурсов и инфраструктур. Избегать стратегий, при которых заказчик становится полностью зависим. Помнить, что такой подход в долгосрочной перспективе невыгоден для всех сторон.

Если клиент обращается с просьбой купить или предоставить ему какой-либо ресурс, необходимо объяснять риски.

Строгие меры безопасности, создаваемые для защиты данных и интеллектуальной собственности, иногда могут создать препятствия для гладкого процесса разработки. Такие условия требуют очень высокой квалификации от специалистов.

DevOps, Team Leads и РПО должны обладать глубокими познаниями и опытом. Оптимально, если такие специалисты будут уровня senior и выше, чтобы они могли адаптироваться к сложным условиям работы, предоставляя решения, которые сочетают безопасность с эффективностью.

От поиска иголки в стоге сена спасет только комплексный аудит, включая исходный код, инфраструктуру и аппаратное обеспечение. Он поможет выявить слабые места и ошибки на старте.

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

Совет: обеспечить участие в аудите таких специалистов как DevOps и Team Lead. Их компетенции и опыт позволят более глубоко оценить архитектуру решения, его инфраструктуру и код, чтобы выявить потенциальные угрозы, узкие места и оптимизировать работу системы. После такого аудита вы получите не только отчет о проблемах, но и практические рекомендации по их устранению.

Конфликты интересов, разный взгляд на проект, непонимание задач и целей — это источники проблем. Чтобы избежать недопонимания, важно создать четкий и прозрачный процесс. Каждому участнику проекта необходимо понимать свои задачи и ответственность. Требования к работе должны быть ясны, а процессы — прописаны и доступны для каждого.

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

Одним из вариантов эффективного управления командой разработки на легаси-проектах могут быть выделенные команды.

1. Support Team

Основная задача: поддержание стабильности проекта и оперативное устранение ошибок.

Состав: эта команда может состоять из специалистов среднего уровня (Middle). Не стоит исключать возможность привлечения в команду подрядчиков, которые способны быстро реагировать на изменения и имеют опыт работы с легаси.

Важность: это «первая линия обороны», их работа направлена на то, чтобы обеспечить бесперебойность.

2. Refactoring Team

Основная задача: оптимизация, реорганизация и модернизация кода.

Состав: сильнейшие специалисты, которые имеют опыт работы с большими проектами, способные понимать сложную архитектуру и делать стратегические решения.

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

3. Feature Team

Основная задача: разработка и добавление новых функциональностей, которые будут актуальными для проекта в будущем.

Состав: творческая группа, которая может экспериментировать с новыми решениями, методологиями и инструментами. Они задумываются о том, что будет востребовано завтра.

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

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