ПЕРЕЕЗД В ИСПАНИЮ 🇪🇸

Я давно мечтал переехать в одну из стран Европы. После долгих изучений и постоянных переездов из страны в страну, стало понятно что нужно где-то обосноваться. Наш с женой выбор пал на Испанию.

1️⃣ Климат
Жене и мне надоела серая московская погода. Либо дикая аномальная жара, либо аномальный холод или отсутствие снега.
Так же, как человек из Сибири, привыкший к холодам и хорошей студеной зиме со снегом, то что происходит в Москве не поворачивается язык назвать это зимой. А я люблю зиму 😞
Осень/весна занимают половину года, а иногда и все 3/4. Слякоть, дожди, серость, все это очень сильно бьет по моральной и продуктивной составляющей.

2️⃣ Менталитет и отношение
Обеденные сиесты в 2 часа, когда можно сгонять домой, покушать, поспать и вернуться домой.
Женщин, детей и даже животных здесь уважают больше чем мужчин. Не поймите не правильно, просто когда в Москве жену страшно посадить одну в такси это не ок.

3️⃣ ВНЖ выдают с российским ИП
Я уже 3 года работаю удаленно как ИП. Испания в начале этого года открыла nomad ВНЖ программу по которой можно получить вид на жительство на 3 года. Процедура пока очень простая с самым низким порогом входа. + принимаю контракты из РФ и ИП в РФ тут котируется.
Дайте знать если интересно, могу сделать отдельный пост, где опишу весь этот длинный путь.

И сейчас как раз занимаюсь подготовкой и подачей документов на nomad ВНЖ.

В данном цикле хотелось бы больше рассказывать о себе, напишите про что интересно почитать:
— С чего все начиналось (школа, универ, самообучение)
— Последний опыт (своя игровая студия, переезды, события последних 2ух лет)

#моя_история@UniArchitect

Retention (R)
Первая и базовая метрика, которой измеряется успешность проекта.

Всего 2 типа:
Classic retention — % пользователей, которые открыли игру на следующий день*
Rolling retention — % пользователей, которые открыли игру на следующий день* или позже

Минусы второго — может измениться в любой момент. Даже если пользователь зайдет в игру в следующий раз на 90 день, он попадет в Rolling R1.

Следующий день* — есть 2 типа интервала от которого можно замерять R:
1. 24h — пользователь будет учтен, если откроет приложение в период 24-48 часов после установки.
2. Calendar — пользователь будет учтен, если откроет приложение на следующий календарный день.

Минус второго — пользователь, который скачал игру в 11:50 вечера и открывший ее в 12:05 следующего дня будет учтен.

Из интересного:
▫️ Изменение R1 — динамика развития проекта
▫️ Rolling R на практике используется редко, чаще упоминается на публике или на слайдах в отчетах
▫️ 24h R можно использовать для быстрого определения эффективности компании. Это работает т.к. мы можем в данном случае измерить возврат 0-го дня.
▫️ Calendar Classic R чаще всего просили показать инвесторы. Многие кто слышал цифры ниже бэнчмарков сразу разворачивались
▫️ Если на старте R1 ниже 20%, а FTUE уже отлажен, то потребуются координальные изменения в core части игры, чтобы проект выжил
▫️ Если на старте R1 около 15 и ниже, то проект дешевле убить чем вытягивать
▫️ Если R1 > 35% это успех

#проект_liveOps@UniArchitect
#метрики@UniArchitect

СЦЕНЫ

Первая проблема, которую я сразу решаю на новом проекте — 4 сцены для управления состоянием проекта.

0.Bootstrap — точка входа и контекст проекта (аналитика, SDK сторов, платежка, конфиги, связь с сервером).

1.Loading — загрузка, авторизация, GDPR, проверка обновлений и прочее что нужно для старта игры.

2.Meta — в основном UI в котором вы тратите накопленные ресурсы на прогресс по игре

3.Core — основная реиграбельная часть

4.Empty — костыль сцена для 100% выгрузки всех ресурсов предыдущей сцены.

Из любой сцены мы можем перейти в любую. Исключение Bootstrap. В нее входим только при запуске игры. И из нее загружаем только Loading.

#проект_с_нуля@UniArchitect

(А|а)рхитектура

Общество движется вперед путем увеличения числа операций, которые может осуществлять, не раздумывая над ними.

Архитектурные подходы (паттерны) в разработке ПО универсальны. Их можно применить к любому языку и проекту. Код, следующий этим принципам, будет ➕➖ одинаков с точки зрения масштабируемости и сложности.

Для меня архитектура проекта — это совокупность решений в организации проекта, обеспечивающие удобство работы и масштабируемость, а так же замедление роста когнитивной сложности.

И при проектировании нужно вырабатывать эти решения (правила, подходы, гайдлайны) не только для кода, но и для всего с чем проект связан:
— Именование файлов и папок, структура хранения ассетов, структура сборок
— Утилиты для разработки, тестирование, работа с системой контроля версии
— Билд проекта и его деплой, работа со сторами и выливка хотфиксов
— Мониторинг метрик, ошибок и реагирование на них

#аббревиатуры@UniArchitect

ПЕРЕКЛЮЧЕНИЕ СЦЕН — Additive.

СЦЕНЫ

Нюансы:
— Загрузка и выгрузка асинхронная, требует написания доп. кода
— Нужно ручками в новой сцене дергать SceneManager.SetActiveScene
Только после этого делать Instantiate объектов.
— Сторонние плагины все равно создают DontDestroyOnLoad объекты

Преимущества:
— Можно отказаться от DontDestroyOnLoad объектов и использовать Bootstrap сцену для хранения глобального контекста.
— Захотели перезапустить игру полностью? Загрузили заново Bootstrap и весь контекст дропнулся без лишних телодвижений
— Очистка памяти и уменьшение используемой RAM без Empty сцен

+ Tutorial можно сделать отдельной сценой, которая при загрузке будет определять какая сцена загружена, какой последний шаг и вести пользователя

#проект_с_нуля@UniArchitect

СТРУКТУРА ВЕТОК ПРОЕКТА

У структуры веток всего 1 требование — деление процесса разработки на понятные стадии.

Из опыта создания нескольких проектов с нуля я выделил такую структуру веток:

🔹 develop — разработка.
- В этой ветке происходит контролируемый разработчиками хаос
- Код в ветке может работать, а может и нет
- Окружения разворачивается локально
- Настройки проекта могут быть какие угодно в зависимости от потребностей разработчиков

🔹 art — стабильная версия develop.
- Нужна геймдизайнерам, QA, аналитикам и т.п. для проверки, тестирования текущего состояния приложения
- Cвое серверное окружение

🔹 stable — feature freeze. Выделяет конкретный список, набор фичей, которые получат пользователи в этом обновлении.
- Сюда мержится develop когда все фичи версии сделаны
- Включена вся отладка
- Включены читы
- Фейковый магазин
- Cвое серверное окружение

🔹 rc — Release Candidate. Это пред-релизная версия.
- В данную ветку мержится stable
- Сюда могут быть залиты только hotfix’ы
- Версия максимально приближена к проду
- Отключена вся отладка
- Конфигурация на максимальную производительность
- Реальный магазин
- База данных синхронизирована с продом

🔹 main/master — тот самый prod, который принято ронять 😬
- Сюда мержится rc
- Состояние из этой ветки всегда соответствует состоянию приложения у пользователей на девайсах.
- В нее может напрямую пушить только лид, либо ответственный за релиз.

Кол-во веток и окружение нужно варьировать в зависимости от потребностей проекта.

#проект_в_разработке@UniArchitect

НАВИГАЦИЯ

Об авторе блога

Open source:
— Unity Empty Project Template 80+⭐️
— Fast Migrations Json .NET 40+⭐️

#проект_с_нуля@UniArchitect — все что нужно знать, когда создаете новый проект

#проект_в_разработке@UniArchitect — все с чем приходится сталкиваться во время разработки

#проект_релиз@UniArchitect — нюансы, процессы, проблемы публикации мобильных проектов

#проект_liveOps@UniArchitect — поддержка, оперирование приложениями, которые уже опубликованы

#аббревиатуры@UniArchitect — высказываюсь на тему популярных аббревиатур

#моя_история@UniArchitect — истории моего карьерного и не только пути

#метрики@UniArchitect — аналитические метрики проекта, которые полезно знать

#будни@UniArchitect — реальные проблемы, с которыми я сталкиваюсь и сразу пишу об этом

#software_engineering@UniArchitect — цикл статей на тему инженерной разработки ПО.
Основа для понимания архитектуры ПО

#курс@UniArchitect — статьи, где я делюсь прогрессом по курсу, который я проработал и создал

Мероприятия:
#DevGAMM_Lisbon_23@UniArchitect

@UniArchitect

FTUE

Для программиста — жизнь это while(true)
Для CG художника — жизнь это lerp(a,b,t)
Для аналитика — жизнь это funnel

В прошлый раз я писал про Retention (R).
Но от чего зависит R и можно ли его как-то предсказать?
— Можно если знать конверсию FTUE воронки.

Воронка (funnel) — последовательность шагов, по которым проходит группа пользователей.
Пример:
— Установка
— Согласие с GDPR (General Data Protection Regulation)
— Загрузка ассетов из CDN (Content Devilery Network)
— Шаги тутора
— Сыгранные N игр в core части

Из прохождения всех шагов складывается первое впечатление пользователя от игры — FTUE.
FTUE (First time user experience) — воронка, которую проходит пользователь до возврата на 1 день.

Замерами мы понимаем эффективность шагов. И если она не достаточная, то мы улучшаем его, делая первый опыт игрока более приятным, тем самым влияя на R1.

Из интересного:
▫️ Для R1 ~30-35% конверсия FTUE должна быть ~60-70%
▫️ Аномальное изменение % отвала между версиями == техническая проблема (софт/хард лок, ANR)
▫️ Эффективность изменений в обновлении == дельта отвала между текущей и прошлой версией
▫️ 500 пользователей — минимально достаточное кол-во, чтобы считать данные репрезентативными

⚠️ Эксклюзив: фрагмент документа с одного из проектов, над которым я работал.

#проект_liveOps@UniArchitect
#метрики@UniArchitect

DI

DI (Dependency Injection) — подход, который абстрагирует создание объекта, выделяя его на отдельный слой и отделяя от основного приложения.
Добавляет концепцию управления зоной использования (scope) и временем жизни объекта.

При том важно разделять:
🔹Composition Root (CR) — паттерн, подход при котором создание объектов системы происходит в одном месте.
Выделяет 3 (RRR) фазы управления жизненным циклом объектов:
- Register — создание зависимостей
- Resolve — решение графа зависимостей
- Release — удаление, освобождение объекта

🔹DI container (DIc 🍆) — как правило плагин, реализация-автоматизация CR.
Т.е. вместо ручного создания и решения графа зависимостей, он через рефлексию или кодогеном сам прокидывает зависимости в конструктор или поля.

🔹Service Locator (SL) — создает, хранит и отдает по требованию любое множество зависимостей
Может быть частью реализации CR, но тогда решать граф нужно самому.
В этом месте, при не понимании RRR, возникает куча проблем (кольцевые зависимости, классы боги) из-за чего SL называют антипаттерном.

Из этого следует:
▫️Реализовать DI можно без использования DIc
▫️DIc (Zenject, Vcontainer и др.) сильно расширяют жизненный цикл любого класса
▫️С DIс мы делегируем обязанность по созданию и управлению жизненным циклом объекта!
▫️Легковестной реализацией DI может быть SL (статический класс со словарем)

При использовании DIc или SL важно навсегда запомнить:
1. Никакой логики в конструкторе. Только агрегация и композиция
2. Вся логика инициализации, как отдельная стадия создания объекта, выделяется в отдельный метод

В случае несоблюдения мы рискуем обратиться к зависимости раньше, чем был решен граф, что сразу == куча головняка с порядком регистрации зависимостей.

Картинка из книги Dependency Injection Principles, Practices, and Patterns by Steven van Deursen and Mark Seemann

#проект_в_разработке@UniArchitect
#аббревиатуры@UniArchitect

КОГНИТИВНАЯ СЛОЖНОСТЬ

В 2009 было опубликована статья.
В ней взяли все типы сложности ПО (см. Table 1, стр. 5), расписали критерии их измерения, написали несколько программ, получили данные и сравнили их по значимости.

Для понимания выводов нужно пояснить:
🔸 Символьная сложность (symbolic complexity, definition. 7, стр. 7) — кол-во строк кода
🔸 Операционная сложность (operational complexity) — сумма весов сложности базовых операций (if, switch, for, while, do-while, function call и т.д. Table. 3, стр. 14)
🔸 Архитектурная сложность (architectural complexity, definition 22, стр. 16) — сумма весов всех аргументов, возвращаемых значений и локальных переменных
🔸 Когнитивная сложность одного объекта (unit of cognitive complexity, definition 24, стр. 17) — произведение операционной и архитектурной сложности объекта
Если совсем просто: все операции объекта, помноженные на все его переменные
🔸 Когнитивная сложность ПО (cognitive complexity) — сумма когнитивных сложностей всех объектов системы
🔸 Сложность связей проекта (relational complexity, definition 25, стр. 20) — произведение кол-ва объектов проекта и кол-ва связей объекта с самым большим кол-вом связей
Т.е. как будто все объекты системы одинаково сложны

Вот несколько сухих выводов оттуда:
1️⃣ Минимальная когнитивная сложность — символьная сложность. Когда архитектурная и операционная сложность = 1.
Т.е. проект без циклов, ветвлений, объектов, вызовов методов и т.д.
2️⃣ Максимальная когнитивная сложность — все объекты одинаково сложны
3️⃣ Когнитивная сложность находится между минимальным и максимальным значениями (corollary 4, стр. 21)
4️⃣ Зависимость между минимальной и максимальной сложностью — квадратичная
Т.е. условные 10 строк кода могут создать максимальную сложность в 100. Если каждая из строк будет вынесена в отдельный класс, в отдельный метод с одним аргументом и одним возвращаемым значением

Душно, да? Давайте своими словами:
🔹 Выделение логики в отдельный метод не всегда равно упрощение
Т.е. если метод с 2мя for'ами разбить на 2 метода по 1 for в каждом, то сложность объекта увеличится в 2 раза 🤷‍♂️
🔹 Сделать объект проще = уменьшить его архитектурную и операционную сложность
Т.е. выделить аргументы в 1 объект, избавиться от возвращаемого значения, уменьшить кол-во локальных переменных и уменьшить кол-во операций
🔹 Уменьшение архитектурной сложности ведет к увеличению сложности связей
Т.е. суммарная когнитивная сложность проекта остается такой же
🔹 Когнитивная сложность проекта всегда растет

#software_engineering@UniArchitect