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

Unite 2025

Черт, сколько раз я пытался попасть на Unite. То COVID все отменял, то логистика не складывалась, то работа не отпускала. За 9 лет на Unity — ни разу не был на их главной конференции.

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

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

🔻19 и 20 Ноября я буду на Unite 2025 в Барселоне, где соберется вся команда Unity и ключевые разработчики индустрии.

Для тех кто будет на конференции — пишите в личку, встретимся офлайн.

Для всех остальных — у меня есть оборудование (микрофон, стабилизатор и телефон), чтобы делать качественные сторис прямо с места событий. Буду рассказывать о докладах, показывать атмосферу, и самое главное — могу задать твои вопросы команде Unity напрямую.

Потому предложение:

🔸 От меня — качественный контент без воды о том как проходит Unite, короткие summary докладов, закулисье конференции + я задам твои вопросы команде Unity и сниму их ответы

🔸 От вас — Boost'ы канала
https://t.me/UniArchitect?boost
Чтобы я мог публиковать больше сторис в день (лимит зависит от уровня канала).

Не стесняйтесь boost'ануть по максимуму — это конвертирует фичу телеги во что-то реально полезное для всех 🫡

🔻И самое интересное:

Напиши в комментариях какой вопрос ты бы хотел задать команде Unity. Я соберу самые интересные и постараюсь получить ответы от первоисточника.

Может это будет про будущее DOTS, или про планы по улучшению производительности, или про новые фичи которые ждем годами — пиши что волнует.

Ты знаешь кому переслать этот пост 💪

#unite2025

ПРОЕКТИРОВАНИЕ: С ЧЕГО НАЧИНАТЬ

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

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

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

🔸Уровень 1: System Context

Любая компания — это система. Набор элементов (отделов, команд, unit'ов), которые взаимодействуют между собой ради глобальной миссии. Для игровой компании — развлечение пользователя.
Для контекста, перечитай (А|а)рхитектура.

На уровне системы нам важно отобразить:
— Пользователя и его способ взаимодействия с системой
— Ключевые элементы, благодаря которым фича будет работать

При этом нас НЕ интересуют детали реализации и конкретные технологии.

🔸Пример: мобильная игра

Общий вопрос для начала:

Кто пользуется системой и что является точкой взаимодействия?

— Пользователь: игрок (Gamer)
— Точка взаимодействия: мобильное приложение (Game)

Какие ключевые элементы обеспечивают работоспособность системы?

У любой игры среднего размера (100к+ скачиваний) есть:

▫️ Tech Monitoring — Firebase Crashlytics, Unity Cloud Diagnostics, Sentry
▫️ Analytics — Google Analytics, Facebook, AppsFlyer
▫️ Game Data Service — админка с доступом к данным пользователя. Обычно своя разработка или MBaaS (Mobile Backend-as-a-Service): Firebase/Unity Cloud Save, AWS Amplify
▫️ Data Storage — хранилище данных пользователя
▫️ CDN — Content Delivery Network для ассетов и конфигов

Из комбинации этих элементов ты можешь собрать архитектуру уровня системы для 99% мобильных игр.

см. картинку или оригинал

🔸Модель C4

Поздравляю, первый уровень модели C4 освоен .

Software System — наивысший уровень абстракции, описывающий нечто, что приносит ценность пользователям.
Это то, что строит одна команда разработки, владеет им, несет ответственность и видит внутреннюю реализацию.
Как правило, граница software system = граница команды.

И вот нюанс... Software System — это НЕ bounded contexts, НЕ product domains, НЕ tribes или squads (организационные единицы Spotify модели).
Это конкретная система, которую нужно встроить в существующий ландшафт. В моем случае — микросервис чата в инфраструктуру компании.

🔻 Минималистичное проектирование начинается с системы, а не с кода. Это экономит время на согласование и избавляет от лишней документации.

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

Это первая статья серии "Проектирование". Дальше по порядку о каждом слое: контейнеры, компоненты, код.
Угадайте какой из них стоит генерировать, а не проектировать ручками? 😅

Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪

#проектирование@UniArchitect

MV*

Сколько копий сломано об эту тему...

Давайте по порядку:
— В 1974-79 годах Trygve M. H. Reenskaug (автор MVC) работал над портативным компьютером "для детей всех возрастов" Dynabook в компании XEROX.
— Именно тогда/там закладывались основы графического интерфейса, формировалось понятие "дружелюбного интерфейса".
— В те же года была и опубликована короткая заметка про разделение на model/view/editor, которая позже преобразовалась в MVC.

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

Давайте попробуем распутать этот клубок, проанализировав первоисточники:

🔸Model:

Модели представляют знания. Модель может быть одиночным объектом (что не очень интересно) или структурой из нескольких объектов.
Между моделью и ее частями, с одной стороны, и представляемым миром, как его воспринимает владелец модели, с другой стороны, должна быть однозначная связь.
MODELS - VIEWS - CONTROLLERS

1. Model — это функциональность, которая возникает при комбинации нескольких систем.
Т.е. это модуль/объект, который вбирает в себя необходимые сервисы системы и использует их для формирования функциональности необходимой для controller/view.

2. Model это не данные, а исключительно интерфейсы/объекты-посредники/фильтры, обеспечивающие удобный доступ к данным, которые могут находится где угодно.

🔸View:

View — это визуальное отображение своей модели. Обычно оно подчеркивает определенные атрибуты модели и скрывает другие, действуя как фильтр.
Представление привязано к своей модели (или ее части) и получает необходимые данные для отображения, запрашивая их у модели.
The original MVC reports

Вспомните пост про ПОРТЫ И АДАПТЕРЫ и представьте что вы пишете код, которые раскрашивает пискели на экране 50 лет назад 😬

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

И как раз для отделения кода связанного с рендером "нужного цвета пикселя в нужном окне на экране" с бизнес-логикой и была выделена view.

🔸Controller:

Контроллер — это связующее звено между пользователем и системой. Он обеспечивает средства для вывода пользовательских команд, предлагая меню или другие способы ввода команд и данных, переводит их в соответствующие сообщения и передает эти сообщения одному или нескольким представлениям.
MVC XEROX PARC 1978-79

Яблоко раздора, вносящее сумятицу во всю систему...

Вместо 1000 слов и долгих объяснений: controller — это выпадающее меню, появляющееся при нажатии на правую клавишу мыши.

Это то, делает отображение сцены в редакторе из 2D в 3D, отключает ненужные gizmos на экране и дает возможность переключать Move, Rotate, Scale, Transform для объектов.

Логика view и model в таком случае никак не меняется. Меняется лишь настройка отображения, которая необходима пользователю для работы.

Вместо длинных выводов:
❌ “Грамотный” UI в Unity всегда должен состоять из model/view/controller.

✅ Нет. В 99.9% случаев вам вообще не нужен controller.
А иногда вы можете и модель не выделять, используя интерфейс сервисов.

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

❗️Потому что изначальная идея MVC удовлетворяет очень узкому набору требований для разработки первого UI для первого портативного компьютера.

И попытка переноса идеи 1к1 приведет лишь к переусложнению вашего проекта (раз, два).

Если вам интересно узнать больше, рекомендую почитать крутой цикл статей на хабре, где автор еще в 2017 году проделал аналогичное исследование 🫡

Это далеко не все выводы, в одной статье невозможно раскрыть столь большой топик.

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

#архитектурные_подходы@UniArchitect

КАЧАЕМ ФАЙЛЫ БЫСТРЕЕ НА 30%

Если вы на старте игры качаете более чем 100 файлов, то есть один забавный способ ускорить загрузку до 30%.

Контента в игре у вас много, а размер билда должен быть <150МБ.
Потому часть вы запаковали в 100 Asset Bundle'ов.
А на старте игры качаете их из CDN через Unity Web Request.

В коде это выглядит примерно так:

IEnumerator DownloadAssetBundle(string url, Action<byte[]> onSuccess)
{
    using var request = UnityWebRequestAssetBundle.GetAssetBundle(url);
    var op = request.SendWebRequest();

    while (!op.isDone)
        yield return null;
    onSuccess?.Invoke(request.downloadHandler.data);
}

Уверен что у каждого в проекте есть похожий кусок.
Есть идеи как его ускорить? 😬

Ответ:
Application.targetFrameRate = 120

Дисклеймер:
Как и всегда, есть нюансы. Перед тем как применять подобное у себя, тщательно изучите ограничения платформ для вашего проекта.

🔸Как так получается?
— Если вы знаете что такое Synchronization Context, то возможно, вы уже догадываетесь в чем дело.
Это специальный класс в dotnet, который представляет из себя очередь delegate'ов на MoveNext (машин состояний), которые будут вызваны в момент когда наше приложение готово продолжить выполнение асинхронного кода.

В unity синхронизация вызывается в UnityEngine.PlayerLoop.Update.ScriptRunDelayedTasks из нативной части, путем вызова статического метода UnitySynchronizationContext.ExecuteTasks.

🔸Или проще говоря:
— Все продолжения ваших асинхронных операций длиннее одного кадра будут вызваны на следующий кадр в Update.ScriptRunDelayedTasks фазе.

🔸Риторический вопрос:
Действительно ли время загрузки файлов по сети привязано к длине кадра?
— Вообще нет. Установление соединения и скачивание идет в другом потоке в нативной части.

Но вот результаты и обновление состояний синхронизированы с основным потоком и происходят в UnityEngine.PlayerLoop.EarlyUpdate.UnityWebRequestUpdate.

🔸Это значит:
Что если файл качается 45ms, а ваша игра работает при 30FPS, то ~15ms данные будут ждать синхронизации.
Того самого вызова MoveNext для вашего метода DownloadAssetBundle.

Т.е. данные в памяти в нативной части будут через 45ms, но у себя вы их получите только через 66ms.
И буст (местами до 30%) можно получить как раз за счет снижения времени "простоя" данных в ожидании вызова нужной фазы PlayerLoop'а.

Это тот забавный случай, когда магическая строчка в одном месте почему-то дает ощутимый результат 🤣
Так что, как идею, берите на вооружение увеличение FPS на время загрузки и возвращение его в нормальное значение после 😅

❗️Но блин, ребят, это не silver bullet. Проверяйте последствия на своих проектах.
На слабых девайсах это может только сделать хуже.

Если интересно копнуть больше в эту тему, рекомендую посмотреть видео с конференции CLRium.
CLRium #6: Контексты синхронизации (SynchronizationContext)

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

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

#будни@UniArchitect

Почему я сделал курс по архитектуре проектов в Unity?

Потому что вижу дикий разрыв между «учебными» рассказами о том, как делать проект, и тем, как всё происходит в реальности.

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

Почему так? Есть несколько причин:

1️⃣ Требования при одиночной и командной разработке — это разные миры.
Отсюда возникают неочевидные задачи: управление конфигами, совместная работа в Git, настройка staging (dev/prod окружения), аналитика, CI/CD, code review.

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

2️⃣ Проклятие знаний.
Часто, поработав в одном проекте, люди думают: «Ну, все же делают так же».

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

3️⃣ NDA.
Из-за жёстких пунктов о неразглашении с большими штрафами никто не рвётся делиться подробностями процессов и архитектуры. Порой вообще неясно, что можно рассказывать, а что нет.

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

5️⃣ Высокая требовательность к себе и сложность материала.
Тема непростая, хочется делать материалы качественно. Да и негатив или токсичность по поводу «недостаточно глубоко раскрыл» мало кому интересны. Проще не выносить ничего в публичное поле.

🔸В итоге имеем кучу базовых «стартовых» курсов, которые не очень помогают, когда ты переходишь на серьёзный уровень в реальном проекте. Что-то более глубокое приходится буквально выискивать по крупицам — да и то не факт, что найдёшь.

Я думал, что этот разрыв закроют k-syndicate в 2022-м, когда они выпустили свой курс по архитектуре. Но они сместили фокус на создание собственной игровой студии, и вопрос снова остался открытым 😬

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

За весь период с января 2023 по сентябрь 2024 я упорно изучал разные книги, научные статьи, базу знаний по реальным проектам, анализировал личный опыт — всё для того, чтобы этот разрыв хоть немного сократить.

Понимаю, что сейчас кругом агрессивные продажи и курсы с обещаниями «200к за 2 месяца», и многие уже устали от подобного.
Но я действительно хочу делиться наработками и продавать результат своей работы — ведь вкладывал в это уйму сил и времени 🫠

🔻Важный момент:

Я не маркетолог и не собираюсь навязывать курс кому бы то ни было, чтобы не выглядеть в глазах аудитории очередным инфоцыганом.

🔸Буду рассказывать о нём в блоге, стараясь делать это спокойно и без агрессивной рекламы. Если кому-то интересно прокачаться с учётом реальных процессов, подтянуть архитектуру и все эти нюансы командной разработки — милости прошу. Если нет — всё нормально, у меня нет цели загонять туда всех подряд.

Главное, чтобы вы понимали, зачем вообще этот курс появился и почему я считаю нужным его продвигать: в реальности сложных игровых проектов слишком много незакрытых вопросов, и хочется, чтобы люди не прыгали в омут с головой без нормальной подготовки 😵‍💫

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

#курс@UniArchitect

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

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

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

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

АРХИТЕКТУРА НА SCRIPTABLE OBJECT

Я уже как лет 6 регулярно отвечаю на вопросы в архитектурном чатике.
И уже 6 лет туда регулярно залетают вопросы в духе:

— А архитектура на Scriptable Object (SO) норм?
— Посмотрел видеоролик Х и Y, думаю сделать проект на SO, что думаете?
— Хочу систему конфигов сделать через SO, что скажете?

У меня есть один почти загубленный проект богатый опыт использования этого подхода.
Отсюда, 6 причин почему SO, скорее всего, станут занозой на большом проекте.

1️⃣ Изменения в SO отображаются в git только после сохранения проекта.
Оо, сколько раз это ломало проект или делало вас "некомпетентным" в глазах других после заливки новой фичи.

Кейс простой:

— У вас есть 50 SO-объектов.
— В 5 из них вы поменяли значение/ссылку.
— Открыли git, сделали commit.
— У вас всё работает, у других — нет. 😱

У меня, честно, глаз дергается каждый раз, когда я меняю что-то в SO.
Жму по 10 раз Ctrl+S и визуально перепроверяю каждый asset-файл на корректность изменений.

2️⃣ SO-объект сохраняет изменения между запусками.
Легко можно получить ситуацию, когда вы указали ссылку на SO-объект в вашем префабе, изменили значение в runtime' e, и это значение осталось в SO-объекте.

И самое страшное в этом — ссылочные типы:

— Вы передали List<T> из вашего SO как аргумент в метод, в котором добавили/изменили/удалили значение
— Та-дам! После того, как вы выйдете из PlayMode, изменения останутся внутри SO

Вот и получается что вроде все настроил, запустил один раз, все работает.
Запускаешь 2 раз и все... А ведь день так хорошо начался 😬

3️⃣ Из пункта 2 → Вы вынуждены копировать данные из SO, чтобы использовать их в runtime.
Вместо тысячи слов — реальный класс в котором все данные копируются в новый SO объект, чтобы изменять их в runtime'е.

И так почти в каждом SO-объекте:
1000 бесполезных строк кода и 10ки MB бесполезных аллокаций. 😭

4️⃣ SO при создании грузит в память все asset'ы на которые ссылается.
Допустим, вы делаете rogue-like игру:

— В игре 100 уровней == 100 префабов
— Вы создаете SO-объект и добавляете туда все ссылки на префабы
— Прокидываете ссылку с SO в объект на сцене
— Запускаете игру и все префабы, на которые указывает ваш SO, успешно загружаются в RAM устройства 😱

Вам нужен один уровень, а в памяти все 100.

5️⃣ Вместе с SO вы тянете нативную часть.
Внутри SO будут вызваны методы, которые являются частью unity.

И этот объект будет дороже в создании как по памяти, так и по производительности.
А также он будет иметь хроническую проблему сравнения с null.

6️⃣ Удаление SO-объекта не показывает файлы, которые ссылались на него.
Как результат, ищи-свищи, в каком из SO-объектов потеряна ссылка. 🫠

А по факту, никто просто не удаляет SO-объекты из проекта, так как это очень багоопасно.
Просто делают новую конфигурацию, что захламляет проект.

Единственное решение:
Через глобальный поиск искать guid файла, который был удалён, во всех *.asset'ах проекта. 😵

🔻Отсюда правила, которые я ввожу на своих проектах, чтобы избежать проблем выше:
🔸Прямые ссылки на SO запрещены.
Только путь до asset'а , либо AssetReference (если есть Addressables).
🔸Любая вложенность SO→SO, Prefab→SO запрещена (если нужна, см. пункт выше).
🔸В SO никакой логики: максимум Pure-методы и get only-свойства.
🔸Ссылки на любые коллекции должны возвращать только IReadOnly*<T> интерфейс.

Итого:
Easy to learn, hard to master.
Для маленьких проектов/прототипов еще может быть.
Для работы в большой команде, кмк, слишком много нюансов, чтобы использовать это как архитектурную основу проекта 🫠

Сохраняй этот пост себе и пересылай коллегам, чтобы держать эти нюансы всегда под рукой. 😎
Ну и делись своим опытом в комментах💪
Ставь 👍, если тебе по кайфу такая движуха!

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

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

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

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

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

@UniArchitect

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

Полтора года назад, когда я только стартанул блог, я опубликовал статью в которой дал свое определение архитектуры:

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

Но это определение, как вы можете заметить, не очень точное.
Т.к. содержит в себе субъективное восприятие через призму личного опыта.
Давайте постараемся это исправить.

🔸И начнем мы с определения от Мартина Фаулера:

Architecture is about the important stuff. Whatever that is.

Архитектура — это про самое важное. Что бы это ни было.
Who Needs an Architect?

Черт, Мартин... Отдаю должное тебе за вклад и работу, но кажется, что с высоты твоего опыта, в дело вступило проклятие знаний.
И такое определение больше запутывает, нежели отвечает на вопросы 😐

🔸Благо университет Carnegie Mellon в 2017 году выпустил статью What is your definition of software architecture?, из которой мы сможем проанализировать несколько определений и выделить в них ключевое.

Начнем с стандарта IEEE:

Архитектура определяется как фундаментальная организация системы, выраженная через её компоненты, их взаимоотношения друг с другом и с окружающей средой, а также принципы, управляющие её дизайном и развитием.
DOI: 10.1109/IEEESTD.2000.91944

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

Если наберем 💯 реакций, я разберу стандарт подробно в отдельной статье 😎

🔸Интересное определение предлагает нам Rational Unified Process:

Архитектура — это набор ключевых решений об организации системы, её структурных элементов, интерфейсов, поведения и их объединения в подсистемы, определяемый выбранным стилем.

🔸Следующее определение предложил создатель модели COCOMO:

Архитектура программной системы включает в себя:
• Набор программных и системных компонентов, соединений и ограничений.
• Набор требований заинтересованных сторон системы.
• Обоснование, показывающее, что компоненты, соединения и ограничения определяют систему, которая при реализации удовлетворит требования заинтересованных сторон.
Barry Boehm

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

И мы можем из этого общего собрать термин, который емко дает всю необходимую информацию и согласован со стандартом:

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

Не хочется раздувать определение, вводя дополнительные комплексные понятия, но я бы еще сделал пометку на полях:

И желательно чтобы эти решения замедляли рост когнитивной сложности проекта 😬

Но в чем точно я не ошибся, когда писал пост полтора года назад, так это в том, что архитектура это далеко не только код!
Но об это по порядку в следующих статьях 🫡

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

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

ВРЕМЯ ПЕРЕМЕН

Последние 4 месяца были очень богаты на события.

1️⃣ Смена места работы

До этого я 1 год и 3 месяца, это уже 3я компания где я проработал ровно такой срок, работал в Datasakura.

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

Но уже как полтора месяца я помогаю решать самые сложные проблемы на проектах компании Playtika.
Это огромный шаг вперед, т.к. это мой первый опыт работы в настолько большой компании (до этого размер был всегда до 1000 человек, а тут ~3600).
И проблемы тут уровня проектов на 100М+ скачиваний 😵‍💫

В общем я очень рад и доволен новым этапом в своей карьере.
Ждите в 25ом моих выступлений на конференциях от меня с докладами по архитектуре проектов на unity 🥄

3️⃣ Мы с моей любимой женой смогли переехать из маленького города Сантандер на севере Испании в Барселону.

И вот вам маленькая история из переезда:

Мы арендовали в Барселоне пустую квартиру без мебели, а собственно нажитой мебели у нас не было (мы всегда снимали полностью обставленные квартиры).

И чтобы первое время хоть как-то спать, мы заказали с Amazon матрас надувной. Хороший, на двоих, 130 евро на секундочку.
Перемещались на поезде мы около 12 часов в сумме, в 10 утра выехали, в 10 вечера приехали.
Уставшие, замученные, заходим в пустую квартиру с 2мя рюкзаками с техникой и документами и 1 надувным матрасом.

Собираемся ложиться спать, чтобы на следующее утро принять машину со всеми вещами, распаковываем матрас, открываем ячейку с электрическим насосом и ... там КИТАЙСКАЯ МАТЬ ЕГО ВИЛКА.

В общем мой отзыв: спать на полу на 2ух слоях занавесок без одеяла в одежде, можно и даже можно выспаться, если очень сильно устать перед этим 🤣

Мы давно планировали этот переезд, долго готовились и для нас это был осознанный выбор, потому мы очень рады.
В Барселоне теперь я на ближайшие несколько лет точно, контракт на квартиру у нас на 5 лет, так что если кто рядом, погнали на бранч (контакты в описании канала) 🥄

4️⃣ Анонс, продвижение, продажа и старт "Вашего последнего курса по архитектуре"

Не переживайте, ничего продавать не буду, только поделюсь результатами 😬

Уже прошло 14 лекций примерно по часу-полтора длиной, где мы разобрали:
🔹 Когнитивный процесс принятия решений (1 лекция)
🔹 Software Engineering (5 лекций)
🔹 Определение архитектуры и имеющиеся архитектурные подходы (7 лекций)

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

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

На курсе в общей сложности 33 человека разного уровня опыта (есть даже сценарист из США 🤯), но в среднем это ребята middle+ уровня с 1+ годом коммерческого опыта разработки игр на unity.

Инсайты о старте своего курса с нуля:
🔸 Проработка и сбор материала с упором на качество занимает от полугода работы по 1-5 часов каждодневной работы после работы 😵‍💫
🔸 Обязательно нужно на каждом этапе продвижения, продажи писать рандомным подписчикам и делать мини customer development.
Сильно влияет на конверсию в покупку.
🔸 У меня в блоге теплая аудитория на технические посты, но холодная на продажи.
Нужен дополнительный элемент воронки, чтобы увеличить показатели конверсии (у меня это был бот с памяткой).
🔸 2 лекции в неделю + работа очень сильно выматывают.
Отпуск раз в 2 месяца обязателен 🏠

Если хочется знать больше деталей, пишите комменты, я человек простой и открытый, поделюсь без проблем 👍
Ставь 👍, если тебе заходит подобного рода контент!

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

Всем привет!

Я Лёша, и вот уже 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

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

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

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

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

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

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

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

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

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

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

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

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

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

СИНДРОМ САМОЗВАНЦА

На первом месте работы, куда я пришел сначала разработчиком, а потом стал lead'ом, мне запомнился один момент.
Я отчетливо помню, как во мне начало по экспоненте расти чувство самозванца.

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

Я видел, как каждый элемент в игре должен функционировать.
Ну... почти каждый. Потому что после проверки игры в playtest cloud добавились новые, сложные требования, связанные с авторизацией, аналитикой, графикой и пр.

🔸В один момент я поймал себя на факте, что должен решать, как что-то будет работать в проекте, не имея ни малейшего понятия, удовлетворят ли эти решения требованиям.

Пример:
Сделать собственные Asset Importer для анимаций персонажей со общим Animation Controller.
И указывать через Animator Override Controllers стейты, которые есть у текущего персонажа.
* см. превью — это универсальный animator controller для более чем 100 противников в игре

Или же поискать другой подход или стороннее решение типа Animancer.

🔸И постепенно объем решений и сложность задач начали порождать во мне ощущение, что я лишь симулирую уверенность и знания.
Потому что не знаю, будет ли это работать по факту.

От этого у меня появилось неконтролируемое чувство тревоги и неуверенности в своих решениях.

И, смотря назад, я понимаю, какая мысль в моей голове положила этому начало:

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

🔻Но это заблуждение! Ты либо знаешь, либо нет.
Очень редко удаётся фундаментально подойти к принятию решения.
Либо времени, либо сил, чтобы тщательно переработать материал, нет.

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

Но то был далёкий 2019, тогда курсов, которые бы мне помогли, не было, а уровень эго не позволял обратиться к кому-то за помощью 😐

А сейчас есть! Я разработал курс, главная цель которого:
🔹Дать полную причинно-следственную связь всех подходов в дизайне и архитектуре.
Это позволит принимать решения более осознанно и качественно!

И побочные эффекты осознанности:
🤓 Избавление от синдрома самозванца.

Переходи по ссылке и записывайся на твой последний курс по архитектуре:
https://uniarchitect.notion.site/

Поспеши! До начала осталось всего 7 дней 🛞

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

ПОРТЫ И АДАПТЕРЫ

Любая программа состоит из 3ех фундаментальных частей:
— Ввод
— Обработка
— Вывод

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

И идея его проистекает из способа работы с железом:
🔹 У нас есть спецификация платы, чипа
🔹 У каждого чипа, платы есть порты
🔹 Каждый порт соответствует пину, ножке чипа
🔹 Проставив значение hot (1) на один из пинов/ножек, мы просим чип выполнять какие-либо операции
🔹 Вывод этих операций мы можем "слушать" с другого порта согласно спецификации

Так мы можем складывать числа, включать/выключать диод на плате, загружать операционную систему.
Для наглядности можно посмотреть это видео с канала Low Level Learning.

И любая работа с железом всегда строилась таким образом:
🔸 Ты пишешь по магическому адресу магическое число (ввод)
🔸 Получаешь по магическому адресу магический ответ (вывод)
Дааа, embedded программирование — чистая магия, не иначе 🤣

А теперь абстрагируемся:
🔹 Любой способ получить данные — ввод
🔹 Любой способ вывести/сохранить данные — вывод
🔹 Преобразование ввода в вывод — сама суть любой программы 🫡

Но мы ведь не работаем с чистыми битами и регистрами, мы просто пишем File.Read, WebRequest.Process и получаем данные в удобном формате.
А раньше работали и каждый по своему мог организовывать ввод и вывод.
Именно из-за особенности связи код-железо и появился архитектурный подход "Порты и Адаптеры".

Суть:
🔸 Порт — это любая абстрактная сущность, которая предоставляет данные.
Мы ее "слушаем" и получаем/отправляем данные
🔸 Адаптер — конвертер/преобразователь в формат представления структур/объектов языка.

Т.е. это простейшее разбиение на 2 операции:
🔹 Отправка/получение данных
🔹 Десериализация (а по факту демаршалинг) данных

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

🔻Это позволяет нам в целом абстрагироваться от способа получения данных и реализовать поддержку бесконечного кол-ва источников.
В том числе мы можем сделать fake источник, тем самым делая возможным тестирование логики.

Этот подход позже был экстраполирован на крупные системы и был переименован в Hexagonal architecture.
Где каждая грань многогранника обозначала свою связку порта и адаптера.

Ремарка:
Название "Порты и Адаптеры (Ports and Adapters)" это второе название Hexagonal Architecture, которая решает проблемы совсем другого уровня.
У меня же в статье "Порты и Адаптеры" никак не связаны с Hexagonal Architecture. Я рассматриваю этот подход отдельно и независимо.
Я позволяю себе такое, потому что следы "Портов и Адаптеров" можно найти задолго до Hexagonal Architecture, например в документации к Apple Macintosh 1992 года 👍

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

Вот пример адаптера с проекта Magic Battle Arena.
Реализацией порта в этом случае был класс TcpServer.

Сохраняй себе, чтобы не потерять и делись с коллегами 📞
Ставь 👍 если тебе заходит такого рода контент!

#архитектурные_подходы@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

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

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

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

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

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

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

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

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

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

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

@UniArchitect
#курс@UniArchitect

АНОНС СТРИМА

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

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

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

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

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

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

@UniArchitect

НЕСОВПАДЕНИЕ КРИВЫХ ОБУЧАЕМОСТИ

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

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

Далее все примерно развивается по одному и тому же сценарию:
🔸 Либо напряженность в коллективе нарастает
🔸 Либо человек "переходит в другую команду"
🔸 Либо человек проявляет конформизм
Т.е. адаптируется, приспосабливается к мнению команды, даже если это противоречит его личным убеждениям

Но есть и другой вариант — человеку удается внести изменение и команда принимает это органично.
Почему у кого-то это получается, а у кого-то нет?

Попав в коллектив, мы имеем какой-то "багаж" знаний и навыков, который может разительно отличаться.
Ведь кто-то учился самостоятельно, кто-то в университете, кто-то чисто на практике.
Каждый путь уникален т.к. зависит от множества внешних и личных обстоятельств.

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

Как это исправить?
🔻 Нужно выровнять уровень знаний в команде
Т.е. аргументированно шаг за шагом привносить новые знания в команду, тем самым подтягивая каждого из его членов до вашего уровня.

Из статьи про нейропластичность мозга пару тезисов:

Обучение не происходит мгновенно, потому что оно связано с формированием новых нейронных связей, укреплением этих связей через повторение и интеграцией новой информации с уже имеющимися знаниями. Мозг генерирует гипотезы о новой информации и сопоставляет их с уже существующими следами памяти. Когда эти сопоставления неоднократно подтверждаются, они приводят к созданию резонансных состояний мозга, которые лежат в основе осознания новой информации
p.1, 1.1. Conscious Perception and Behaviour the Limiting Factor.

Короче говоря, путем интервального повторения по чуть-чуть доносить информацию, на протяжение какого-то времени. На моей практике от 3 месяцев.

Реальный пример с работы:
На одном из проектов было очень странное требование:

Для каждого класса мы создаем Dispose/OnDestroy метод в котором присваиваем каждому полю класса null.

❗️См. скрин к посту — это ответ одному из разработчиков почему это не обязательно делать.

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

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

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

Выводы:
🔸Лично я, первые 3-6 месяцев не предлагаю ничего улучшить в проекте.
🔸Любая система склонна проявлять конформизм к новому.
Чтобы его преодолеть, нужно поднимать общий уровень знаний.
Если сделать практику workshop'ов каждый месяц, будет значительно быстрее.
🔸Когда уровень знаний выровнялся, можно проявлять инициативность и предлагать конкретное изменение.
🔸Время, затраченное от первого упоминания до внесения изменения зависит от начального уровня знаний.
Выше уровень — меньше времени до внесения изменений.

Обязательно делись своим опытом внесения изменений в комментариях!
Ставь 👍 если тебе по кайфу такой контент!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#курс@UniArchitect