Ловушка универсализации

Что будет

1. Проблема2. Наблюдения3. Варианты решения4. Эксперимент5. Решения для менеджера6. Решения для программиста7. Практика в Unity8. Вопросы

Prime World (PC)

Prime World: Defenders (PC, iOS, Android)

Blitzkrieg 3 (PC, Mac, Linux)

Etherlords (iOS, Android)

Что сделает программист если ему не “мешать”?

Бесполезно потраченные ресурсы на:• добавление не востребованного

функционала (универсализация, “переиспользование” компонент)

• излишнее упрощение (наведение красоты, чрезмерный рефакторинг)

Следствие:• Падение мотивации менеджеров

Дороговизна разработки• Усложненная инфраструктура

Проблема

Наблюдения

Тезисы:• Программисты любят упрощать (путь

наименьшего сопротивления/красота)• Часто это не выгодно• Дольше в разработке не значит лучше (есть

некоторый предел, по сравнению с забором)

Варианты решения

На теории:• Архитектор• Технический дизайн

На опыте:• Ретроспективы• “Чужие” компоненты• Метрики пора/не пора универсализировать

Легко считается только при “заказе” всех изменений

Аппроксимации

N – число ревизиий конкретной ветки/папки

Аппроксимации

M = цикломатическая сложность,E = количество рёбер в графе,N = количество узлов в графе,P = количество компонент связности.

Аппроксимации

N – число функцийM – число вызванных функций в эталонном запуске

Эксперимент

Не сработало:• Метрики• Архитектор

Сработало:• Ретроспективы• Технический дизайн• Упрощение компонент

Решения для менеджера

Направлять желание сделать “правильную” систему для часто модифицируемых элементов

Примеры+: игровая логика, отладка, обслуживание, стабильность серверов/клиентов, аналитика, нотификации оператора, размер клиента, процесс сборки (opt)

Примеры-: рендер, логи, архитектура (на поздних стадиях)

Решения для программиста

1. Больше доверять программистам, которые не вы

2. Понимать позицию заказчика3. Не тратить силы на порицания4. Передавать опыт/технологии5. Находить время подумать о деталях

Практика в Unity

Требования к компоненте:• Тестируемость• Гибкость• Надежность

Сильные стороны Unity API:• Асинхронность без callback• Компонентный подход• Reflection редактор• Runtime обновление public значений

Практика в Unity

Под что в Unity нужно адаптироваться:• Смешанные MVC компоненты• Слабоуправляемый конвеер вызовов• Слабоуправлямая работа с памятью• MonoBehaviour должен находиться на

GameObject

Практика в Unity

Варианты архитектуры:• “Скриптовать”• Делить на ActiveComponents + Managers• Адаптировать архитектуру под Unity

компонеты (IHTTP, IUnityData, IUnityView...)

Выводы

1. Выделение компонент необходимо2. Нужно понимать разницу между

практичностью и увлеченностью3. Делать проще чем хотели часто хорошее

решение4. MVP бывает и на уровне проектирования

Индекс Хирша (h-индекс)

nival.comgamesjam.org

oleg.chumakov@nivalnetwork.comtwitter.com/gamescodedogs