Монолитный GameManager на живом проекте: как разбирать его без остановки релизов
Живой мобильный проект с релизами раз в две недели. Вся клиентская логика собралась в классе GameManager на четыре тысячи строк: там и состояния приложения, и покупки, и звук, и сохранения, и вызовы аналитики. Задача — привести клиент к модульной структуре, не останавливая выпуск фич. Какой подход здесь рабочий?
- Заморозить фичи на спринт и переписать GameManager целиком: иначе архитектура получится половинчатой, а два подхода в одном коде запутают команду
- Оставить GameManager как есть и писать все новые системы рядом, не трогая старые вызовы: со временем он перестанет использоваться сам собой
- Разбить файл на несколько частей одного класса по зонам ответственности: это уже даёт модульность и не создаёт вообще никакого риска для релизов
- Вытаскивать по одной ответственности за раз, закрывая её интерфейсом сервиса: проект остаётся выпускаемым на каждом шаге