nival: Как не увлечься погоней за универсализацией...
DESCRIPTION
Если оставить программиста одного — он будет делать суперуниверсальное нечто. Какие компоненты было бы действительно полезно сделать универсальными и как понять когда универсализация это пустая трата времени.TRANSCRIPT
Ловушка универсализации
Что будет
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
[email protected]/gamescodedogs