Nival: Как не увлечься погоней за универсализацией компонент
Download as PPTX, PDF0 likes749 views
Документ обсуждает проблемы универсализации в разработке программного обеспечения, такие как бесполезная трата ресурсов и падение мотивации команды. Приводятся варианты решений для менеджеров и программистов, а также примеры практики разработки на Unity. Также ведется речь о важности выделения компонентов и различия между практичностью и увлеченностью в процессе разработки.
Nival: Как не увлечься погоней за универсализацией компонент
- 2. Что будет 1. Проблема 2. Наблюдения 3. Варианты решения 4. Эксперимент 5. Решения для менеджера 6. Решения для программиста 7. Практика в Unity 8. Вопросы
- 4. Prime World: Defenders (PC, iOS, Android)
- 5. Blitzkrieg 3 (PC, Mac, Linux)
- 7. Что сделает программист если ему не “мешать”?
- 8. Проблема Бесполезно потраченные ресурсы на: • добавление не востребованного функционала (универсализация, “переиспользование” компонент) • излишнее упрощение (наведение красоты, чрезмерный рефакторинг) Следствие: • Падение мотивации менеджеров Дороговизна разработки • Усложненная инфраструктура
- 9. Наблюдения Тезисы: • Программисты любят упрощать (путь наименьшего сопротивления/красота) • Часто это не выгодно • Дольше в разработке не значит лучше (есть некоторый предел, по сравнению с забором)
- 10. Варианты решения На теории: • Архитектор • Технический дизайн На опыте: • Ретроспективы • “Чужие” компоненты • Метрики пора/не пора универсализировать Легко считается только при “заказе” всех изменений
- 11. Аппроксимации N – число ревизиий конкретной ветки/папки
- 12. Аппроксимации M = цикломатическая сложность, E = количество рёбер в графе, N = количество узлов в графе, P = количество компонент связности.
- 13. Аппроксимации N – число функций M – число вызванных функций в эталонном запуске
- 14. Эксперимент Не сработало: • Метрики • Архитектор Сработало: • Ретроспективы • Технический дизайн • Упрощение компонент
- 15. Решения для менеджера Направлять желание сделать “правильную” систему для часто модифицируемых элементов Примеры+: игровая логика, отладка, обслуживание, стабильность серверов/клиентов, аналитика, нотификации оператора, размер клиента, процесс сборки (opt) Примеры-: рендер, логи, архитектура (на поздних стадиях)
- 16. Решения для программиста 1. Больше доверять программистам, которые не вы 2. Понимать позицию заказчика 3. Не тратить силы на порицания 4. Передавать опыт/технологии 5. Находить время подумать о деталях
- 17. Практика в Unity Требования к компоненте: • Тестируемость • Гибкость • Надежность Сильные стороны Unity API: • Асинхронность без callback • Компонентный подход • Reflection редактор • Runtime обновление public значений
- 18. Практика в Unity Под что в Unity нужно адаптироваться: • Смешанные MVC компоненты • Слабоуправляемый конвеер вызовов • Слабоуправлямая работа с памятью • MonoBehaviour должен находиться на GameObject
- 19. Практика в Unity Варианты архитектуры: • “Скриптовать” • Делить на ActiveComponents + Managers • Адаптировать архитектуру под Unity компонеты (IHTTP, IUnityData, IUnityView...)
- 20. Выводы 1. Выделение компонент необходимо 2. Нужно понимать разницу между практичностью и увлеченностью 3. Делать проще чем хотели часто хорошее решение 4. MVP бывает и на уровне проектирования
- 22. nival.com gamesjam.org oleg.chumakov@nivalnetwork.com twitter.com/gamescodedogs