Unity Architect: архитектура unity проектов

КОДОГЕНЕРАЦИЯ

Фича, которая реже всего встречается на проектах, где я работал.

Что странно, ведь это очень эффективный инструмент с очень высоким отношением затрат и результата, и вот почему:

1️⃣ Единственный способ увеличить продуктивность программистов — использовать кодогенерацию.

Т.е. генерировать код, для создания которого требуется сформировать абстрактную модель в голове, а потом перевести ее в реальный код.
С учетом того что цикл перевода знаний из краткосрочной в долгосрочную память занимает больше 24 часов (об этом я писал тут и тут).

2️⃣ Вы тратите время только на поддержку кодогенератора, а не кода, который он генерирует.

Если в сгенерированном коде баг — исправляем генератор, а не все объекты, что он создал.
Такая же логика работает для всего, что генератор создает.

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

3️⃣ Это очень легко.
Чем отличается генерация JSON-файла от генерации скрипта?
— Вообще ничем. Любой класс — это текст внутри файла.
Компилятор увидит эти файлы, сотворит магию (нет) и код будет готов к использованию.

Вот крутой пример из самого популярного DI-контейнера для Unity (всего 90 строк кода 🤯).
Никаких хаков и продвинутого понимания языка. Просто код, который генерирует код 😅

4️⃣ Это может быть очень быстро.
Вместо использования рефлексии можно сгенерировать код, который будет вызывать нужные методы напрямую.

Из популярного:
🔸Операции (де-)сериализации
Например, тот же Newtonsoft.Json использует IL Weaving для генерации IL-кода, который преобразует строку в объект во время исполнения программы.

В unity же значение в каждый из элементов объекта проставляется через рефлексию.
Жду реализации через SourceGenerator'ы 🛞

🔸Генерация Data Transfer Object'ов
Для общения клиента и сервера, вместо того чтобы писать объекты для данных вручную, можно их полностью генерировать.
Безусловно, такая фича уже давно есть в Swagger и много где еще, но в игровых проектах я все равно встречаю такое редко.

Чаще генерация происходит через первый сайт в google'е 🫠

🔸 Связь с нативной частью Unity.
Например, перехват событий из Animation Event можно полностью сгенерировать.
Тем самым избежав типичных: "Ой, эффект на персонаже X перестал работать, посмотри чо там 🥺".

Мы этот подход использовали на проекте Magic Battle Arena и полностью генерировали из имен fbx-объектов:
🔹 События анимации, которые вызывали нужный метод в коде
🔹 Уникальные типы анимации для каждого персонажа.
Каждый персонаж — свой enum, который всегда консистентен с анимациями, которые на нем есть.
🔹 Настройки для художников спецэффектов.
Добавил fbx, нажал одну кнопку, настройки со всеми типами анимации готовы за 1 секунду.

5️⃣ Можно генерировать целые фичи.
На Magic Battle Arena мы генерировали DTO, (де-)маршалинг данных и Memory Pool для всех этих объектов 😎

Т.е. по сути весь транспортный слой, отвечающий за коммуникацию клиента и сервера, полностью кодогенерировался.
Мы использовали T4 Templates. До сих пор очень мощный и крутой инструмент 🫡

Итого:
Лично для себя не вижу ни одного повода чтобы не задавать себе каждый раз перед написанием новой фичи:
"А могу ли я какую-то часть накодогенить?"🤔
Так шаг за шагом и проект сам себя рано или поздно напишет 🤣

🔻Давайте соберем маленькую базу мест, где еще кодоген будет полезен.
Расскажите в комментах, где вы используете(-али) кодоген и он сослужил вам верную службу 🫡

Ты знаешь кому переслать этот пост.
Ставь 👍 если тебе по кайфу такая движуха

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

🎁 Уже завтра розыгрыш!

Я с ребятами все это организовывал, попробуйте залететь, вдруг повезет 😜

МНОГОСЛОЙНАЯ АРХИТЕКТУРА: ПРEМЬЕРА ВИДЕО

Начинаем через 5 минут, подключайся скорее 🛞

Разберем:
🔸Структуру организации и то как она копируется в структуру проекта
🔸 Как можно представить любую игру на unity в виде слоев
🔸 Пример структуризации проекта моей студии silverfox games

➡️ССЫЛКА НА ПРЕМЬЕРУ

@UniArchitect

МНОГОСЛОЙНАЯ АРХИТЕКТУРА: ПРЕМЬЕРА ВИДЕО

Я долго думал какую активность можно замутить в преддверии Нового Года.

Потому я просто взял 10ю лекцию вашего последнего курса по архитектуре и выложил ее на youtube 😎

✏️ Потому завтра в 19:00 МСК встречаемся на моем youtube канале.
Посмотрим видос, пообщаемся в чатике трансляции и хорошо проведем время 😊

Разберем:
🔸Структуру организации и то как она копируется в структуру проекта
🔸 Как можно представить любую игру на unity в виде слоев
🔸 Пример структуризации проекта моей студии silverfox games

Ставьте себе уведомление и до встречи 👋

➡️ ССЫЛКА НА ПРЕМЬЕРУ

@UniArchitect

🎁Новый год — новые клавиатуры! Участвуй в розыгрыше 13 топовых механических клавиатур!

Мы, совместно с шестью каналами по разработке игр, решили устроить для вас настоящий новогодний сюрприз! Вместо стандартных поздравлений мы решили организовать масштабный розыгрыш с крутыми призами — 13 полноразмерных высококачественных механических клавиатур с LED-подсветкой, которые подойдут как для разработчиков игр, так и для геймеров. Победители смогут выбрать цвет клавиатуры на свой вкус!

📌 Условия участия просты:

1. Подпишись на 6 каналов:
💋 Unity Architect
💋 Baxx Studio
💋 Kozlov Dev
💋 Сазонов о Web
💋 Григорий Дядиченко
💋 GameDev. Путь Самурая

2. Нажми кнопку «Участвую».

🗓 Результаты будут объявлены 31 декабря в 20:00 в канале Baxx Studio. Победителей выберет RandomGodBot.

За арт спасибо @hellbrush_art

🎄 Желаем удачи и с наступающим Новым годом! 🎄

Всем привет!

Я Лёша, и вот уже 9 лет работаю с Unity, а около 5-6 лет помогаю компаниям разрабатывать игры на Unity.

Большую часть своей карьеры я занимал позицию Lead, создал несколько проектов с нуля, а также пару лет назад мы с партнёром привлекли 400k$ и пытались создать свою игровую студию.

Более подробно об этом опыте вы можете почитать в статьях:
1️⃣ КРАТКИЙ КАРЬЕРНЫЙ ПУТЬ
2️⃣ SILVERFOX GAMES НАЧАЛО
3️⃣ ЖИЗНЬ ПОСЛЕ SILVERFOX

Последний год я работал в компании Datasakura откуда помогал компании Zeptolab улучшать их проекты в числе которых:
✈️ Overcrowded: Tycoon Idle Plane
😊 Cut The Rope: Daily

Полный список мест, где я работал, и проекты, над которыми трудился, вы найдёте в моём LinkedIn:
https://www.linkedin.com/in/alexey-kozorezov/ <— закидывайте connect, добавлю всех 😊

В этом канале я стараюсь писать про архитектуру Unity-проектов, а также обо всём, что так или иначе связано с Unity.
Иногда делюсь историями о своей карьере под тегом #моя_история.

Самые популярные статьи:
1️⃣ МЫ ИНЖЕНЕРЫ, НЕ ХУДОЖНИКИ
2️⃣ ПРИЧИНА И СЛЕДСТВИЕ
3️⃣ КОГНИТИВНАЯ СЛОЖНОСТЬ Ч.2. <— есть еще первая часть, обязательно чекните 😉

Так же есть навигация, не стесняйтесь пользовать hashtag'ами, чтобы найти статьи на интересующие вас темы 😊

🏠 Я живу в Испании и недавно переехал в Барселону.
Буду рад встретиться на бранче, если вы живёте рядом или проездом 🥄

Этот блог я постепенно хочу превратить в платформу для разработчиков уровня middle+, где каждый сможет найти ответы на сложные вопросы о нюансах работы в Unity.
Подробнее об этом я рассказывал в своем посте ЦЕЛЬ

И напоследок:
🔸 Я простой разработчик-самоучка, с длинным, сложным и извилистым карьерным и жизненным путем.
Я вырос в маленьком городе в Сибири и постепенно с нуля как-то добрался до блога и Барселоны.

🔻Моя цель — заполнить пробел в информационном вакууме между уровнями junior и senior в разработке игр на Unity, с фокусом на материалы, которые можно перепроверить самостоятельно.

Таким образом это будет win-win для всех:
Для вас — качественный контент, а для меня — ресурсы, которые я могу конвертировать в образовательную деятельность.

Ставь 👍, если вам по кайфу такая движуха!
Ну и, добро пожаловать 🫡

@UniArchitect

СОЗДАЕМ СВОЮ ИГРОВУЮ СТУДИЮ

У меня за плечами есть опыт создания не большой игровой студии.

Для тех кто пропустил:
Раз, Два

Прохождение сложного этапа поиска инвестора и перевода средств — это лишь начало.
Следующим шагом нужно открыть компанию, которая сможет принимать заработанные средства из Apple Store и Google Play, а так же платить зарплаты и за обслуживание серверов.

Основные шаги:
🔸 Выберите локацию для компании
🔸 Найдите посредника для удалённого открытия
🔸 Определите тип компании

Возможные локации:
🔹 США (Делавэр)
🔹 Сингапур — здесь зарегистрирована silverfox.games
🔹 ОАЭ

Лучшие типы компаний по гибкости и минимальной операционке:
🔸 Ltd., LLC — продвинутый аналог ООО, где акции распределяются, а ответственность несёт компания, а не вы.

Компанию открыть несложно (с помощью платформ типа Stripe и Osome), но с банковским счётом сложнее.

К счастью, можно найти растущие нео-банки (tier-2, tier-3), и примерно через 2-4 месяца у вас будет компания, готовая принимать платежи и оплачивать сервисы.

И последний барьер, который нужно преодолеть:
❓ Выплаты зарплат из за рубежа в РФ и наоборот.

И это большая проблема. В Silverfox в пике расходы за оплату труда переваливали за несколько миллионов в месяц.

А такие объемы проводить каждый месяц, это не счет за ресторан разделить 😅
У банка и валютного контроля быстро появятся вопросы.

Пару лет назад я использовал промежуточные счета в странах СНГ, с которых потом переводил все на счет компании в Сингапуре.

Но это то как это было у меня 2 года назад.

🔻А сейчас благо уже ребята подсуетились и сделали удобный сервис: salary.cab

⚡️Они с минимальной комиссией и платеж в чистую проведут и всю документацию закрывающую сгенерируют.

Потому что одно дело подписать договор, другое дело делать по нему платежи и всегда под рукой иметь документацию, чтобы счета неожиданно не заморозили. 😱

Я вот все доки ручками делал и на эту мантру у меня уходило по 4-6 часов в день зарплат.

А с salary.cab экономил бы кучу времени 😊

Получать ЗП из за рубежа и получать все бенифиты от плавающего курса оч приятно. 🥰

Ну, а дальше дело за малым:
Сделать успешную игру 😅

@UniArchitect

НАПИСАЛ 3 СИСТЕМЫ АБИЛОК С НУЛЯ И ВОТ ЧТО Я ПОНЯЛ

Для системы, в которой будет удобно работать важно:

1️⃣ Отделить данные от бизнес-логики
Т.е. объект игрока/героя/персонажа со всеми данными должны быть полностью отделены.

И это нужно не для тестирования или потому что так Дядя Боб завещал, а для свободной модификации в любом месте.
Данные ходят из слоя в слой из системы в систему по разными причинам:
🔸 Для отрисовки UI
🔸 Для отправки по сети
🔸 Для модификации в других системах
🔸 Для отката в предыдущее состояние
В случае десинхронизации клиентов или неправильным изменением данных (выход за пределы рабочих значений)

И если сделать данные частью какого-то объекта (агрегировать их) , то нужно будет таскать везде его.

Правила для легкой масштабируемости:
🔹 При добавлении контекста не связанного домена использовать композицию, не наследование.
Перегружать данные в наследнике = ломать совместимость моделей между системами/фичами.
🔹 Если работаете с сервером, то сначала принимаете данные, потом показываете изменение игроку.
Эта пауза необходима, иначе не будет времени проиграть все красивые анимации и эффекты.

Минусы:
— Нужно жестко следить за порядком изменения данных.
Модификация в неправильный момент может сломать всю логику.

2️⃣ Не создавать мелкий кипиш. 1 абилка - 1 класс для всей логики.
Вам не нужен этот SRP, вы заплатите высокой когнитивной сложностью системы (раз, два)

3️⃣ Порядок и правила применения в одном месте.
Бизнес-правила верхнего уровня (управление порядком применения/добавления/удаления/синхронизация) на верхнем слое в одном месте.
Весь кипишь с модификацией данных, проигрыванием эффектов, изменения UI и т.д. внутри.

4️⃣ Сервис абилок лишь предоставляет API для их применения
Он лишь выступает фасадом, что агрегирует в себе все сервисы по работе с абилками.
А внешние сервисы лишь вызывают методы в нужный момент игры (клик пользователя, ответ от сервера и пр.).

Таким образом у вас получается одно место где вы можете управлять всеми абилками.
А поскольку это фасад, то вся логика размещенная в разных подсистемах жестко ограничена.

Что делает саму систему Clear (прозрачной) для понимания по Cynefin framework'у.
А значит легкой для работы и внесения изменений без сторонней помощи.

Темы про:
🔸 Многослойность архитектуры
🔸 Cynefin framework'у
🔸 Когнитивной сложности

👇И многое другое, уже есть в курсе:
https://uniarchitect.notion.site/

Записывайся скорее, осталось всего 6 дней до старта!

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

РОЛИК АРХИТЕКТУРА КОНФИГОВ

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

Его поставили на новый проект в котором нужно было наладить процесс работы с конфигами.

В видео:
🔸 Какие неформальные требования есть к системе работы с конфигами
🔸 Несколько подходов, как можно организовать работу с ними.
Через third party сервисы и через собственное серверное решение
🔸 Рассказал как были устроены конфиги на проекте Magic battle Arena
+ несколько фишек по работе в Google Sheets

Ссылка на ролик: https://youtu.be/8fqkRFSCATg

Приятного просмотра 😎

@UniArchitect

ОТЛАДКА СБОРКИ ANDROID ПРОЕКТОВ

Все мы знаем каким изнурительным бывает процесс поиска проблемы с зависимостями для android.

Как правило в проектах часто используются сторонние third party решения для рекламной медиации, конфигов и атрибуции пользователей
Чаще всего это:
🔸Firebase
🔸IronSource
🔸AppsFlyer
🔸Facebook

И не менее часто после импортирования в проект одного или нескольких решений, билд перестает успешно собираться. мем 🤣

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

Duplicate class android.support.customtabs.ICustomTabsCallback 
found in modules browser-1.4.0-runtime.jar (androidx.browser:browser:1.4.0) 
and jetified-androidx.browser.browser-1.0.0-runtime.jar (:androidx.browser.browser-1.0.0:)

И таких примерно 5000 строк

Что это вообще значит?
🔻 Это ошибка в решение графа зависимостей нативных пакетов в android проекте.
У нас есть сборщик maven или gradle, который анализирует проект, берет все версии зависимостей и качает их в проект.

Т.е. IronSource имеет зависимость A, которая требует зависимость B.
А Firebase имеет зависимость B, но другой версии.
И оба пакета используют одно и то же, но разных версий.

При том зависимости есть 3 уровней:
🔹Проект - то что вы указываете в проекте
Мы можем поправить
🔹Пакет - то что указано в импортированном пакете
Мы можем поправить
🔹Компиляция - версии нативных компонентов android
Можем только плакать😭

И вот вы получаете лог в 20МБ в котором тупо список дублирований каждого класса в конфликтных зависимостях.
О том как такое исправлять на youtube никто не выложит. Это скучно, долго и сложно 😴

Дальше я поделюсь процессом, как я решаю подобного рода проблемы:
1️⃣ Импортируем android проект и открываем в android studio
Build -> Android -> Export Project
2️⃣ Когда проект без ошибок открывается и синхронизируется, в проекте UnityLibrary -> build.gradle файл
И комментируем task'у с компиляцией IL2CPP кода — вызов метода BuildIl2Cpp
Тем самым мы сразу экономим кучу времени на компиляции проекта.
3️⃣ По очереди комментируем каждую зависимость, которая прописана в dependencies и смотрим отключение какой зависимости(-ей) убирает ошибки.
Записываем ее в блокнотик.
4️⃣ Переходим на сайт mvnrepository.com и смотрим какие зависимости используются проблемным пакетом
5️⃣ Включив только проблемную зависимость по очереди включаем все зависимости и смотрим с чем конфликтуем
6️⃣ Пытаемся изменить версию пакетов таким образом, чтобы ошибка ушла
Или удаляем один из пакетов 🤷‍♂️
У меня так было с одной старой зависимостью facebook, 100% там бэкдор от спец. служб 😅

Так же этот процесс можно перенести на сторону unity и сделать resolve зависимостей через EDM4U
Обычно, если есть конфликты, то EDM4U изменит версии пакетов и напишет об этом в консоли.
Что может значительно сократить время на поиск, подсветив конфликтный пакет.

Что еще может помочь:
🔸Перегенерировать все gradle, xml, properties файлы что лежат в Plugins/Android
🔸Ручками скачать зависимости из удаленного репозитория
🔸Переместить их в папку Plugins
🔸Если зависимость типа aar, так же скачать pom файл и прописать все зависимости из него в dependencies внутри build.gradle
🔸Или развернуть собственный maven репозиторий в котором вы поправите версии зависимостей в pom файле

Ну и секретный метод, в случае если ничего не помогло:
Вырываем листик из блокнотика, крепим к кукле-вуду и тыкаем иголкой пока ошибка не уйдет 🤬

На случай если ваш проект после обновления unity перестал собираться, потому что версия gradle была обновлена с версии 4 на 7+, рекомендую держать это пост в сохраненках.
Иначе как у меня пара недель уйдет на сборку и отладку.

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

Ставь 👍 или оберег не сработает 🤣

#будни@UniArchitect

Какую игру делаем?

⬆️Цель проекта: демонстрация построения архитектуры приложения, оценки и выбора различных подходов и решений, применяемых в разработке относительно соотношения цена/качество (под ценой имеется ввиду человекочасы, конечно), а также демонстрация интеграции различных сторонних плагинов аналитики, рекламы и пр. - все то, что применяется на практике в 99% проектов.

Опираясь на различные комментарии в посте, а также на собственные желания, интересы и возможности (временнЫе), я насобирал вот какую игру:

❓Жанр: симулятор градостроения - мерж - Idle - 2048

🔝Идея: Игроку предстоит строить и мержить здания, расположенные на ограниченной сетке. Каждое здание приносит софт или хард валюту, или имеет другие эффекты (потенциал для расширения). Валюту приносит в Idle режиме, то есть без участия игрока. Мерж зданий увеличивает уровень здания, и в последствии доходность. На скорость добычи валют, а также на количество могут действовать различные эффекты (бафы, дебафы, временные, постоянные). Эффекты добавляют найденные предметы, которые собираются в отдельном, ограниченном по объему месте (аналог инвентаря). У зданий есть топовый уровень, после которого мержить нельзя, эти здания имеют особенный эффект. В игре присутсвует N-ое количество таких цепочек зданий (от 1 уровня, до max). Игрок играет "Уровень", это по факту карта-сетка ячеек (город), где нужно выполнить конечную цель в различных условиях левелдизайна. Когда конечная цель выполнена, игрок может перейти в следующий город. Монетизация, как обычно, рекламная + внутреигровые покупки. Платформа - любая на ваш выбор.

Те, кто хочет подсобить артом (3D мир, UI), звуками/музыкой, геймдизайном - милости просим, пишите в комменты или в ЛС (но имейте ввиду, могу отвечать долго).

‼️WARNING‼️: Не думайте, что это будет быстро, вжух и готово! Это будут доолгие месяцы разработки в ультрамедленном режиме. Мы строим YouTube проект, большой проект, на это тоже нужно время. Даже работая фултайм на такое уйдет не один месяц. Спасибо за внимание!

ВАШ ПОСЛЕДНИЙ КУРС ПО АРХИТЕКТУРЕ | СТАРТ ПРОДАЖ

Закончился стрим, на котором мы разобрали научную статью "Когнитивный процесс принятия решений".

В ходе анализа мы выяснили, какой фактор помогает перейти от управления вероятностью исхода события к действиям, которые ведут к увеличению profit'а и сокращению cost'ов.
Ссылка на запись

Этот стрим был нулевой лекцией моего курса, из которой можно понять, в каком формате будут проходить все занятия.

🔻Во время стрима состоялся ОФИЦИАЛЬНЫЙ СТАРТ ПРОДАЖ.

Всю информацию о курсе, его целях и особенностях вы сможете подробно прочитать в статьях:
🔸 ВАШ ПОСЛЕДНИЙ КУРС ПО АРХИТЕКТУРЕ Ч.1
🔸 ВАШ ПОСЛЕДНИЙ КУРС ПО АРХИТЕКТУРЕ Ч.2
🔸 ВАШ ПОСЛЕДНИЙ КУРС ПО АРХИТЕКТУРЕ Ч.3

Или на сайте, где есть ответы на часто задаваемые вопросы:
https://uniarchitect.notion.site/

📞 Хочешь записаться прямо сейчас, пиши мне: @vangogih

Кол-во мест ограниченно!
Продажи заканчиваются уже 6 Октября.

Поспеши, пока есть места!
До встречи на курсе 👋

@UniArchitect
#курс@UniArchitect

АНОНС СТРИМА

Завтра в Воскресенье в 15:00 МСК проведу стрим на тему "Процесс принятия решений".

На нем я расскажу основы того, как принимаются решения человеком.

План:
🔸Разберем научную статью по когнитивному процессу принятия решений
🔸Посмотрим как это влияет на сроки и стоимость проекта
🔸Найдем первоисточник, причину почему разработчиков волнует архитектура
🔸Ну и под конец состоится старт продаж Вашего последнего курса по архитектуре

Это будет самое начало, основа на которую будет опираться весь дальнейший материал!
Нулевая лекция курса из которой можно будет понять в каком виде и формате будут проходить все занятия 🫡

Ставь себе уведомление о начале трансляции:
📎https://youtube.com/live/zSf2rvH9cWw

Завтра в 15:00 МСК встречаемся на стриме 💪

@UniArchitect

ВАШ ПОСЛЕДНИЙ КУРС ПО АРХИТЕКТУРЕ Ч.3

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

Т.е. не просто набор best practices, который устареют через какое-то время, а в знания, которые позволят принимать решения на проектах годами.

Чтобы этого достичь, в курсе будет большой теоретический модуль, в котором будет:
🔸Теория по инженерной разработке
🔸Разбор имеющихся архитектурных подходов
🔸 Анализ текущих метрик качества кода и способы их измерения
Этим мы заложим основу, которая будет всегда актуальна!

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

Именно это мы будет обсуждать в 3ем модуле: Подробный план курса
Цель которого — найти каждый элемент, который требует принятия архитектурного решения.

🔻И каждый проект это море непринятых кем-то решений!

Иногда мы не знаем, где и как нужно принимать их, а также как правильно фиксировать и добиваться их выполнения.

Нет единого документа или статьи, которые можно использовать как чек-лист перед релизом, чтобы убедиться, что всё учтено.

🔸Поэтому я подготовил памятку на 10 страниц, где собраны ключевые элементы каждого проекта, требующие архитектурного подхода.

Этот документ всегда будет у вас под рукой, помогая выявить, что ещё не учтено в проекте, предложить варианты и внедрить их.
Это простые действия, которые приведут к значительным результатам!

По кнопке ниже, вы сможете прямо сейчас открыть бот и скачать памятку с рекомендациями 🫡

Ставь 👍 если тебе заходит подобного рода контент!

#курс@UniArchitect

Комментарии можно оставлять под эти постом 😅

Буду знать что посты в ТГ не поддерживают и кнопки и комменты 😬

ВАШ ПОСЛЕДНИЙ КУРС ПО АРХИТЕКТУРЕ Ч.2

В прошлом посте мы признали разрыв в уровне контента.
Теперь важно понять, как его устранить и какие темы необходимы.

Процесс был долгим и сложным.
Анализируя материал, я постоянно задавался вопросами:
🔹"Какая информация действительно нужна для принятия качественных решений?"
🔹"Что необходимо для целостного усвоения всей информации в курсе?"
🔹"Каких знаний мне самому не хватает?"
🔹"Насколько эта информация важна?"

Так постепенно сформировался список тем, которых не хватает в стандартном информационном пространстве разработчика.
Оставалось лишь переработать и объединить их в единое целое 😊
Ну вроде изян! мем 🤣

Вот немного цифр:
🔸Суммарно в основу курса легла основа примерно из 50 источников
В основном это были научные статьи, книги, видео, профессиональные блоги и документация.
🔸С января 24-го на проработку всего этого ушло более 300 мифических человеко-часов 😬
То есть, каждый месяц уходила полная рабочая неделя на проработку в течение 8 месяцев.
🔸На подачу материала уйдёт в сумме около 40 часов — по 8 часов на каждый из 5 модулей!

Изначально мне хотелось максимально убрать зависимость курса от моего времени и физических ресурсов.
Но чем дольше я работал над материалом, тем больше понимал, насколько долго это всё может затянуться.

У меня был план, которого я придерживался:
🔹Проработать, структурировать материал, подготовить конспекты для видео.
🔹Записать и смонтировать видео.
🔹Сделать сайт-лендинг, где была бы собрана вся информация в удобном виде.
🔹Соединить его с платформой для обучения.

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

Поэтому я принял решение, что первый и единственный поток я проведу лично в формате онлайн-лекций!

И я хочу признаться:
Не получится сделать что-то действительно полезное и крутое, варясь только в котле собственных мыслей.
Как и любая игра, курс требует полировки и качественной обратной связи.

Что будет включено:
🔸Доступ к закрытому телеграм-каналу, в котором будут публиковаться все материалы:
Записи, презентации, список источников и, возможно, текстовые конспекты лекций.
🔸Индивидуальный разбор кейсов и ответы на вопросы.
🔸Доступ к курсу на платформе после релиза.
🔸А также главная фишка, киллер-фича:
Персональный доступ к реальному проекту Magic Battle Arena!

Это уникальная возможность не только получить полезные знания, но и отточить их, работая над реальным проектом, который я лично разрабатывал в своей игровой студии Silverfox Games.

Для меня это способ вдохнуть вторую жизнь в этот проект, а для вас — отличный пример и источник знаний!
Получается win-win 😎

Переходите по ссылке и смотрите полный план курса со всеми темами!

Спасибо всем большое за активность в предыдущем посте.
Я прислушался к каждому из комментариев и подправил план курса 🫡

Делитесь с коллегами и боссами, уже через пару недель состоится открытие продаж!
Ставь 👍, если уже с нетерпением ждешь этого!

#курс@UniArchitect

С ПОЛЕЙ РАЗРАБОТКИ: REVERT MERGE COMMIT

Я работаю с git только через консоль.
Мне не нравятся все GUI, которые имеются на рынке. Т.к. часто они плохо решают узкие, сложные кейсы, которые порой возникают.
Текущий пост прекрасный тому пример, ибо через git GUI встроенный в райдер я не смог решить проблему ниже.

Ситуация:
Есть баг, которые вы правите перед релизом. У вас в голове два решения:
🔸 По уму, но дольше и большим объемом регресса.
🔹 Поправить точечно, грязно, но быстро, внедрившись в другую систему.

Конечно как и подобает доблесть, выбираем первый вариант. Делаем фикс, примерно в 3-6 коммитов, проверяем в редакторе, отправляем в QA.

И вроде опыта достаточно, много всего знаешь и проверил все перед заливкой, но:
🔹 На мобилках фикс не работает.
Там другое графическое API, отличное от редактора и там твой баг вообще не исправлен, а наоборот приводит к hard lock'ам из-за неправильной сортировки UI элементов в очереди на отрисовку.

И вот вы с лидом (или как лид) думаете как исправить это.
Изменения расползлись по другим веткам, а с момента вашего merge commit'a уже прошло пару дней.

Надумали два путя:
🔹 Удалить фикс всех веток.
Можно сделать как через rebase всех изменений после ваших изменений, а потом force push'ем обновить все ветки.
Можно ручками сделать cherry-pick, а потом force push'ем обновить все ветки.
🔹Сделать revert merge коммита.

Проблема с первым:
🔸Придется блокировать работу во всех ветках на время отката.
🔸Во время rebase могут возникнуть конфликты из-за которых можно накуролесить на --выходные и ++пара бессонных ночей.

Со вторым проблема в том, что ХЗ как сделать revert целого merge'а.
И ответ совсем не очевидный:
git revert -m 2 или 1 <merge_commit_hash>

С revert понятно, а что за магия с 2 или 1?

Приготовьтесь, инфу про git оч сложно запаковывать компактно 😅

git — это направленный ацикличный граф, ноды которого всегда хранят в себе hash родителя(-ей).
Т.е. каждый git commit -m "the best changes" создает новую ноду в которую записывает hash parent коммита (hash коммита предшествующий текущему) и hash object-tree.

Для простоты понимания git — это два независимых LinkedList'а один - для изменений (object-tree) второй - для коммитов (commit-tree).
Только LinkedList'ы однонаправленные (нету Next) и могут иметь несколько нод (Node<T>[] Previous).

Это значит:
🔸 Все коммиты в ветке однонаправленно связаны с самым первым Initial commit.
Т.е. из любого коммита в ветке можно дойти до самого начала графа.
🔸 Каждый коммит, без указания parent'а, как нода из LinkedList'а, Previous которой равен null.
Угадайте как их можно удалить? 🙃
🔸 Эта структура отлично подходит для добавления/изменения/удаления.
С поиском сложнее, но благодаря сортировке префиксов по алфавиту (см. папку objects), используется бинарный поиск.

С устройством разобрались. Дальше порядок работы merge:
1️⃣ Находим общий коммит.
Просто идем по графу, пока parent'ы не совпадут.
2️⃣ Ищем diff от общего коммита до последних коммитов в двух ветках.
3️⃣ Полученный diff пишем в merge-commit.
4️⃣ В parent у merge-commit'a прописываем последниE коммитЫ из двух веток.
Т.е. merge-commit, в отличии от обычного имеет 2 parent'а.

Это фактически значит:
🔻git merge не меняет родителей у существующих коммитов (в отличие от rebase), а создает новый, с ссылками на 2 последних коммита в ветках.

А revert-commit может иметь лишь один parent.

Значит, чтобы сделать все правильно, нужно указать изменения какого именного из parent'ов мы хотим revert'нуть.
Или по другому: diff какой из ветки мы должны revert'нуть

За это как раз и отвечает магическое 1 или 2 — номер parent'а, изменения которого мы хотим revert'нуть.

Лично у меня случилось 2 озарения:
🔶 Именно merge-commit несет в себе все изменения.
Revert'нули его == revert'нули изменения всех коммитов.
🔶 Все, rebase, cherry-pick есть маленькая merge операция. А не наоборот.
До этого я думал что merge - аналог rebase 🤯

Но помните, вы этим самым, вы делаете revert изменений, не истории.

Ставь 👍 если такая движуха тебе по кайфу!

Источники:
Ответ с SO
Статья раз
Статья два

@UniArchitect #будни

ЦЕЛЬ

Каналу стукнул год ❤️‍🔥

Много всего получилось сделать за это время:
— 90+⭐️ Шаблон пустого проекта с архитектурой, которую я стараюсь использовать на всех своих проектах
— ~50⭐️ Плагин для миграции json файлов
— 2 статьи на хабр:
- Архитектура unity проектов
- Миграция json файлов
— Написать несколько полезных welcome статей в другие каналы:
- Полиморфизм системы
- UnityEngine.Object == null
- Архитектура и рендер
— Посетить DevGAMM Lisbon
— Помочь найти работу одному крутому senior'у 😎
— Набрать 1400 крутых, активных подписчиков

В общей сложности я написал около 50 содержательных постов, где постарался поделиться своим опытом и подходом к архитектуре.
Не стесняйтесь пользоваться навигацией, за год было куча всего, что вы могли пропустить 😉

За такой большой промежуток времени сложно быть последовательным если нет принципов по которым ты пишешь статьи.
Я для себя сформулировал их так:
🔸 Удобство чтения
Каждая мысль отделена отступом, каждые важный пункт выделен
🔸 Экономия времени читателя
Статьи должны экономить время, давая максимальную пользу.
Выводы должны быть однозначны и соответствовать выводам из источника.
🔸 Качество важнее времени
Не пытаться выдавить контент в какой-то срок.
Писать по кайфу, когда есть силы и желание. И не важно сколько времени прошло с последнего поста.

Я не планирую заканчивать работать над блогом, а наоборот, хочу его развивать.
Моя цель:
🔻 Создать единое место откуда разработчики с 1+ год коммерческого опыта работы с unity смогут найти всю информацию касательно сложных технических нюансов при работе с unity.

Все мы в знаем о таких блогах как: Catlike Coding, JacksonDunstan, Alan Zucconi
Я как самоучка вычитал все эти блоги вдоль и поперек.
И как никто другой хочу не только брать, но и отдавать.

Потому за следующий год я планирую:
🔹 Запустить сайт-блог
🔹 Объединить идею качественных статей с качественными курсами
🔹 Полученные ресурсы использовать, для того чтобы писать статьи, видео, которые будут экономить время на самостоятельное погружение в узкие и сложные темы

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

Так что это только начало, человек я амбициозный и терпеливый.
Уверен что все получится 💪

Спасибо каждому за то что остаетесь со мной 🥰

Ставь 👍 тебе по кайфу такая движуха!

@UniArchitect