Публикация была переведена автоматически. Исходный язык: Русский
Когда вы делаете мобильную игру небольшой командой, главное - скорость.
Быстрая проверка гипотез, мгновенные правки, отсутствие инфраструктурных ритуалов.
В таком режиме архитектура должна помогать вам двигаться быстрее, а не тянуть одеяло на себя.
И вот здесь Zenject - со всей своей элегантной философией - неожиданно превращается в тормоз. Не из-за плохой реализации, а из-за несовпадения масштаба инструмента с масштабом задачи.
Ниже - три коротких наблюдения из практики маленьких команд.
1. Время - ваш главный ресурс. Zenject умеет его есть.
В прототипе важнее всего - time-to-market.
Но DI-фреймворк добавляет «налог» к каждой простой операции.
Пример из реального мира:
• UI-панель - обычное маленькое окно.
• Загружается через Addressables.
• Поверх этого - Zenject-контейнер, installers, инъекции.
Результат: окно может открываться 10-15 секунд, хотя внутри нет ничего тяжёлого.
Вся команда смотрит логи и пытается понять, почему, распутывая этот клубок. И из-за инфраструктурного веса даже такая тривиальная задача, как "показать окно" может превратиться в целый квест на четверых.
В маленькой команде каждая секунда на счету. Не стоит тратить её на ритуалы, которые не добавляют ценности ни игроку, ни продукту.
2. Проект перестаёт читаться в Unity. Чтобы понять логику, нужно лезть в код.
DI делает зависимости невидимыми.
У вас есть префаб - окно, враг, системный объект.
На нём есть скрипт - его «мозг». Но в инспекторе нет ни одного параметра.
Настройки лежат где-то в отдельных ScriptableObject’ах или инсталлерах, а взаимосвязь спрятана внутри кода.
Чтобы понять, откуда объект берёт данные, вам нужно:
1. открыть скрипт,
2. вычислить, какой конфиг он ожидает,
3. попытаться вручную найти этот конфиг в проекте.
Unity при этом не умеет искать «все объекты такого типа», так что вы буквально идёте на охоту за артефактами.
Это означает, что:
• геймдизайнер не понимает, как настроить объект;
• художник не может понять, откуда берется неверный спрайт;
• продюсер не может быстро проверить логику.
Проект начинает читаться только из кода, а не из Unity UI и инспектора.
Это резко снижает гибкость команды и ограничивает участие не-программистов.
3. DI добавляет новый слой риска при сборке. Иногда - критичный.
Zenject активно использует рефлексию.
IL2CPP и Managed Stripping любят выкидывать «неиспользованный» код.
Если не настроить link.xml / Preserve, можно получить билд, в котором:
• часть Zenject-кода стёрта оптимизацией,
• контейнер не может корректно стартовать,
• игра просто не загружается.
Иногда сборка выглядит успешной, но приложение превращается в чёрный экран.
Это не баг игры - это побочный эффект инфраструктуры, требующей постоянного ручного ухода.
Для маленькой мобильной команды это роскошь: вы тратите часы не на контент, а на отладку архитектурной прослойки.
4. Когда скорость важнее изящества
Для маленькой игры в раннем продакшене важнее всего:
• прозрачная структура,
• лёгкость конфигурации,
• понятность в Unity для всей команды,
• минимальное инфраструктурное трение.
Проще накопить небольшой технический долг и потом его точечно рефакторить, чем строить тяжёлую «идеальную» архитектуру с первого дня. Тем более, что быстрые проекты имеют свойство меняться на лету - и иннфраструктуру лушче закладывать, когда основы уже более-менее устоялись.
Ближе к прототипу - проще, прямолинейнее.
Ближе к релизу - умный рефакторинг по необходимости.
Не обязательно использовать DI, чтобы проект был аккуратным.
ScriptableObject-конфиги, локальные сервисы, небольшие «feature-контейнеры» часто работают быстрее и чище в условиях маленькой команды.
Итог
Zenject - отличный инструмент.
Но как любая мощная система, он окупается только при большом масштабе.
Если вы делаете маленькую мобильную игру, где важнее скорость, гибкость и читаемость - вам, скорее всего, будет проще без DI. Не потому что он плохой, а потому что он слишком тяжёл для задачи, в которой выигрывает тот, кто бежит быстрее.
Когда вы делаете мобильную игру небольшой командой, главное - скорость.
Быстрая проверка гипотез, мгновенные правки, отсутствие инфраструктурных ритуалов.
В таком режиме архитектура должна помогать вам двигаться быстрее, а не тянуть одеяло на себя.
И вот здесь Zenject - со всей своей элегантной философией - неожиданно превращается в тормоз. Не из-за плохой реализации, а из-за несовпадения масштаба инструмента с масштабом задачи.
Ниже - три коротких наблюдения из практики маленьких команд.
1. Время - ваш главный ресурс. Zenject умеет его есть.
В прототипе важнее всего - time-to-market.
Но DI-фреймворк добавляет «налог» к каждой простой операции.
Пример из реального мира:
• UI-панель - обычное маленькое окно.
• Загружается через Addressables.
• Поверх этого - Zenject-контейнер, installers, инъекции.
Результат: окно может открываться 10-15 секунд, хотя внутри нет ничего тяжёлого.
Вся команда смотрит логи и пытается понять, почему, распутывая этот клубок. И из-за инфраструктурного веса даже такая тривиальная задача, как "показать окно" может превратиться в целый квест на четверых.
В маленькой команде каждая секунда на счету. Не стоит тратить её на ритуалы, которые не добавляют ценности ни игроку, ни продукту.
2. Проект перестаёт читаться в Unity. Чтобы понять логику, нужно лезть в код.
DI делает зависимости невидимыми.
У вас есть префаб - окно, враг, системный объект.
На нём есть скрипт - его «мозг». Но в инспекторе нет ни одного параметра.
Настройки лежат где-то в отдельных ScriptableObject’ах или инсталлерах, а взаимосвязь спрятана внутри кода.
Чтобы понять, откуда объект берёт данные, вам нужно:
1. открыть скрипт,
2. вычислить, какой конфиг он ожидает,
3. попытаться вручную найти этот конфиг в проекте.
Unity при этом не умеет искать «все объекты такого типа», так что вы буквально идёте на охоту за артефактами.
Это означает, что:
• геймдизайнер не понимает, как настроить объект;
• художник не может понять, откуда берется неверный спрайт;
• продюсер не может быстро проверить логику.
Проект начинает читаться только из кода, а не из Unity UI и инспектора.
Это резко снижает гибкость команды и ограничивает участие не-программистов.
3. DI добавляет новый слой риска при сборке. Иногда - критичный.
Zenject активно использует рефлексию.
IL2CPP и Managed Stripping любят выкидывать «неиспользованный» код.
Если не настроить link.xml / Preserve, можно получить билд, в котором:
• часть Zenject-кода стёрта оптимизацией,
• контейнер не может корректно стартовать,
• игра просто не загружается.
Иногда сборка выглядит успешной, но приложение превращается в чёрный экран.
Это не баг игры - это побочный эффект инфраструктуры, требующей постоянного ручного ухода.
Для маленькой мобильной команды это роскошь: вы тратите часы не на контент, а на отладку архитектурной прослойки.
4. Когда скорость важнее изящества
Для маленькой игры в раннем продакшене важнее всего:
• прозрачная структура,
• лёгкость конфигурации,
• понятность в Unity для всей команды,
• минимальное инфраструктурное трение.
Проще накопить небольшой технический долг и потом его точечно рефакторить, чем строить тяжёлую «идеальную» архитектуру с первого дня. Тем более, что быстрые проекты имеют свойство меняться на лету - и иннфраструктуру лушче закладывать, когда основы уже более-менее устоялись.
Ближе к прототипу - проще, прямолинейнее.
Ближе к релизу - умный рефакторинг по необходимости.
Не обязательно использовать DI, чтобы проект был аккуратным.
ScriptableObject-конфиги, локальные сервисы, небольшие «feature-контейнеры» часто работают быстрее и чище в условиях маленькой команды.
Итог
Zenject - отличный инструмент.
Но как любая мощная система, он окупается только при большом масштабе.
Если вы делаете маленькую мобильную игру, где важнее скорость, гибкость и читаемость - вам, скорее всего, будет проще без DI. Не потому что он плохой, а потому что он слишком тяжёл для задачи, в которой выигрывает тот, кто бежит быстрее.
Поделиться
