КОНФИГИ Ч.1 АРХИТЕКТУРА

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

Сделать хорошо сразу — сэкономить уйму времени на всех этапах разработки.

Конфиги решают всего одну проблему:
🔻 Создание/модификация параметров игры/приложения у пользователя без пересборки проекта

Дополнительные требования:
1️⃣ Удобство работы: понятный для непрограммистов софт, не требующий дополнительных знаний
2️⃣ Доступность: отсутствие необходимости платить и устанавливать доп. софт
3️⃣ Гибкость: может потребоваться задавать любые форматы данных в параметрах. От чисел и строк, до листов, формул и прогрессий.
4️⃣ Вариации для окружений: для каждого окружения разработки - своя вариация конфигов
5️⃣ Поддержка A/B тестов: возможность делать несколько вариаций значений одного параметра
6️⃣ Обновление в реальном времени
7️⃣ Частичная раскатка новых конфигов с возможностью отката

На проектах с которыми приходилось работать, я встречал реализации:
🔹 UI в unity, который отдает json, который статикой кладется в сервер и отдается клиентам на старте
🔹 ScriptableObject'ы в проекте
🔹 Поход клиента напрямую в google sheets, скачивание таблички и парсинг при каждом старте приложения
🔹 Использование сторонних SaaS решений

Все эти варианты имеют место быть, но каждый из них, так или иначе, не отвечает всем требованиям.

🤓 Разминка: для каждой из реализаций назовите номера требований, которые сложно будет реализовать?
Ответ:
🔹 UI в unity: не удобно (прогерам под каждое новое поле нужно делать изменения в коде), не доступно (потенциально в большой компании придется на каждого ГД по лицензии покупать). 1️⃣2️⃣
🔹 ScriptableObject'ы - вообще ни одно из требований удовлетворить не может. 1️⃣—7️⃣
🔹 Напрямую в google sheets: только 6️⃣, но у google есть лимиты на кол-во запросов в минуту + credential'ы нужно зашивать в билд, что не безопасно
🔹 SaaS решения: если хорошее решение то проблемы, скорее всего, будут только с 3️⃣4️⃣7️⃣.

В идеальном мире, я бы делал так:
🔸 Маленький проект на C# или скрипт на питоне, который умеет: ходить в google sheet, скачивать табличку, преобразовывать ее в json формат и считать хэш-сумму полученного файла
🔸 Машинка, которая слушает команды и запускает проект/скрипт. По факту любого бесплатного runner'a встроенного в любой remote git сервис
🔸 CDN (Content Delivery Network) мультирегиональный в который кладется финальный json и файлик с хэшом
🔸 Логика на клиенте, которая умеет формировать правильный адрес, чтобы забирать нужную версию конфигов.
Ну и логика сверки локального хэша конфигов и удалённого, для обновления

В Silverfox получилось сделать только так, на остальное не хватило времени и потребностей:
— Часть с созданием json'а была на сервере
— Связь с табоицей, парсинг и отдачей клиенту занимался сервер. От клиента только подключиться к правильной версии 😎

А если сервера нет:
— Парсер встроить в клиент
— Класть финальный json ручками напрямую в Firebase
— Использовать Firebase Remote Config как CDN

🎉Тадам 🎉
Сложно? На самом деле черт страшен лишь на вид:
🔸 Для связи с google sheets есть хорошо задокументированная SDK
🔸 Парсер и схема структуризации таблиц уже готова
(не использовал, но писал подобное сам, потому что легко и быстро)

А как вы на проектах работаете с конфигами? — Пишите в комментах!

Вторая часть будет про версионирование 🛞

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

ВЫГОРАНИЕ

В 2015 я впервые познакомился с unity, в 2017 я нашел первую работу, когда учился на 3 курсе универа, в 2019 присоединился как разработчик в молодую компанию Chillgaming с которой мы делали проект Combat Quest.

Параллельно этот проект стал для меня не только первым игровым проектом в моем портфолио, но и первым проектом на котором я выгорел.

Своими словами выгорание — это дикая апатия к делу, к которому ты еще вчера горел. Это чувство полной опустошенности и желание не иметь ничего общего с делом, которому ты отдал большую часть своей жизни.
Если вы, потратив несколько лет на изучение, практику и работу чувствуете что-то подобное — вы выгорели 😵

Я выгорал дважды. И оба раза сценарий один:
🔹 Усердно работаешь, сохраняя средний уровень производительности. Иногда работаешь чуть больше, иногда чуть меньше.
🔹 В один момент нарушаешь этот баланс.
Может быть босс "дал добро" на переработки, может быть вы по "личным соображениям" (самосаботаж, fake it till you make it и пр.) начали работать больше.
🔹 Переработки становятся частью жизни.
8 часов рабочих превращаются в 9 или 16, а между выходными и рабочими днями размывается граница
И самое страшное, организм подстраивается под уровень нагрузки и прежние ужасные "задержался на работе" становятся рутиной

И вот после нескольких недель супер продуктивности, когда так много удается делать, а таски перемещаются в Done одна за одной появляется он:
🔻СТРАХ. Страх потерять в прежнем уровне продуктивности, подвести команду, проект, жену, собаку, себя самого.

Если пропустить, не осознать момент появления этого страха, то он возьмет верх над чувством усталости, измотанности и вы 100% выгорите. Вопрос 1-3 месяцев.

Последствия:
🔸 Продуктивность постепенно падает до нуля
Финальная стадия — отрицательная продуктивность: ваши задачи уходят другому разработчику.
🔸 Становится абсолютно не важно что будет дальше. Срыв сроков, выговор, увольнение? — Плевать, даже думать об этом сил нет.
🔸 Чувство отвращения к любимому делу на срок от 3 до 9 месяцев.
х2 к сроку восстановления, если нет возможности позволить себе не работать все это время.

В сухом остатке:
🔸 1 месяц продуктивности оборачиваются в до 9 месяцев отходняка.
🔸 Проекту плевать на вас и ваши переработки.
Даже если вам за это заплатили, проект, в глобальной перспективе от вашего самопожертвования только минусы. Либо нового сотрудника искать, либо вас из отпуска ждать + время на восстановление.

Как отходить:
🔹 Принять тот факт, что вы выгорели. Чем быстрее - тем лучше.
🔹 Взять отпуск. Чем дольше - тем лучше.
Если вернуться раньше срока, можно опять впасть в апатию или раш, потому что образ мысли остался тот же.
🔹 Сменить место, уехать куда-нибудь на время, в место где вы чувствуете себя хорошо, но где ничего вам не напоминает о работе.
К бабушке в деревню например 🏠
🔹Отдыхать, гулять и просто ждать.
У меня каждое из выгораний проходило только со временем.
Хакнуть систему у меня не получалось, потому что привыкал к переработкам постепенно, менял образ и ритм жизни тоже постепенно.
В одночасье отказаться от этого и жить как прежде не получится.

Я к чему это: у меня на проекте лид ушел в принудительный отпуск на месяц. Сгорел бедняга 🫡
И как человек эмпатичный, мне грустно от этого 🫠

Хочется, чтобы хоть кто-то, прочитав этот пост, решит лично для себя, что свои выходные/отпуск, он проведет не думая о работе.
Полностью переключившись, удалив с телефона slack и выйдя из всех рабочих акков на телефоне и компе.
Проиграв все время в игры или проведя время с любимыми людьми.

🎄С Новым Годом, берегите себя, отдыхайте качественно 🏕

Пост вбирает лишь мои личные ощущения, эмоции и чувства, которые я испытывал, когда выгорал.
Если вы сталкивались с этим, расскажите свою историю в комментах ❤️‍🔥

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

КОНФИГИ Ч.2 ВЕРСИОНИРОВАНИЕ

Структура конфигов в многом копирует (должна копировать) структуру веток проекта
Т.е. каждая ветка смотрит в свою версию конфигов - в свою google таблицу грубо говоря.

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

Вот случаи, когда "конфиги ломаются" чаще всего становятся несовместимы друг с другом:
🔹 Большая фича, которая сильно изменяет структуру конфигов
Если разраб будет менять одну версию конфигов в своей ветке, рано или поздно его версия станет несовместима с другими ветками
🔹 Конфликт веток разработки
Т.е. в версии кода/конфигов в ветках различаются и разрабатывать новые фичи параллельно с релизом не получается.
🔹 ГД работает над балансом и меняет тип данных

Проблемы с пунктами выше будут только если будет 1 версия конфигов на все ветки, а именно:
🔸 Блокировка работы всей команды до момента синхронизации конфигов и кода в ветке(-ах)
🔸 Потенциальная поломка конфигов в проде

Как решить:
🔹 Каждая версия проекта - своя версия конфигов
🔹 При слиянии веток версия конфигов меняется на актуальную

ВЕРСИОНИРОВАНИЕ

Пример:
1️⃣ Стартуем проект с нуля. Все ветки версия 100 (условно)
2️⃣ Как только происходит feature freeze и проект мержится в stable, создается копия конфигов (версия 200) с которой работает только develop.
3️⃣ Выкатка: rc и master по мере слияния смотрят в 100 версию
4️⃣ После релиза master сливается в develop. Изменения из master конфигов переносятся в develop.
5️⃣ Повторить шаги до следующего релиза

Есть нюанс на пункте 4️⃣:
Может быть ситуация когда версия 100 уже не совместима с версией 200.
Но в 99.9% версия 100 структурно является подмножеством версии 200 и нужно лишь пару полей скопировать из одной таблицы в другую.
На крайний случай master данные имеют приоритет и старая 200ая версия удаляется. Делается копия от master версии 200 и ручками восстанавливаются потерянные данные.

Плюсы:
🔸 Возможность бесшовной выкатки. Версия 100 смотрит в свои конфиги, 200 версия в свои. Это позволяет избежать downtime'а, когда версия 200 уже в сторах, но нужно время для пользователей версии 100 чтобы обновиться.
🔸 Снижение до минимума простоя из-за сломанных конфигов внутри команды

Минусы:
🔹 Больше телодвижений и другой подход к работе в команде и способе выкатки в prod.

Что можно упростить:
🔸 В маленьких командах от веток rc и stable можно отказаться и иметь всего 2 версии конфигов для develop и master
🔸 Можно создавать конфиги новой версии на шаге 4️⃣, а не на шаге 2️⃣. Тогда проблема с шагом 4️⃣ можно забыть

Как работать если фича требует поломки конфигов:
🔹 Работа над фичей ведется в отдельной ветке.
🔹 Просто копируем таблицу, локально или делаем копию прям в google sheets и ставим ссылку на локальную копию
🔹 Синхронизируем данные и структуру при слиянии ветки

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

А как по вашему версионирование конфигов вообще нужно в проекте или это over engineering? 🤔

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

АРХИТЕКТУРА И РЕНДЕР

Имеют ли они хоть какую-нибудь связь?

Архитектура - это способ организации кода, который отвечает на вопросы:
🔸 Какие элементы будут и какова их ответственность
🔸 Как они будут создаваться и уничтожаться
🔸 Как они будут общаться между собой

Хорошая архитектура позволит:
🔹Не переписывать код при изменении или добавлении требований (разве что лишь маленький кусочек)
🔹Улучшить производительность всего приложения. Причем этот пункт куда важнее, чем при написании обычных скриптов
🔹Позволит легче искать/исправлять баги

Вот конкретные кейсы, когда рендер о части рендера нужно думать заранее:
🔸Когда пишешь свой SRP (Scriptable Render Pipeline)
🔸Есть, пишется свой кастомный шейдер (аля убер-шейдер)
🔸И даже если у тебя уже готовый рендер: Built-in, URP, HDRP, но нужно написать какие-то кастомные фичи

Вот список вопросов, на которые нужно ответить на каждом проекте:
🔹Тени будут или будем fake'ать
🔹Какое способ орисовки, порядок opaque/transparent
🔹Postprocessing нужен ли
🔹Промежуточные pass'ы будут ли и где
🔹Различные пресеты настроек, крутилки художественные (причем некоторые из них должны переопределяться в сцене, а какие-то даже на участке сцены).

ШЕЙДЕРЫ

Странно, но шейдеры это тоже программа, которая просто пишется на другом языке.

Вот почему код в шейдерах и в *.cs файлах одинаков с точки зрения архитектуры:
🔸Находится так же внутри проекта, компилируется, исполняется своим runtime'ом на конечном устройстве
🔸Зашивается и исполняется на клиенте
🔸Можно выносить общую функциональность в отдельные методы.
В отдельные .hlsl файлы и подключать их как include'ы в шейдеры и в другие include'ы.

Соответственно проблемы, которые нужно решать очень похожи, термины местами просто другие:
🔹Какую функциональность куда подключить и нужно ли это вообще
🔹Как должны общаться функции для лучшей производительность и удобства
🔹Как следует подключать include'ы, в каком порядке, как разместить методы в них, по какому признаку
🔹Кого как и почему вынести под keyword'ы и как их организовать

CUSTOM RENDER FEATURE

Допустим, что-то элементарное:
🔸Игрок кликает на юнита и юнит должен получить обводку.
🔸Как сообщить материалу о том, что вот сейчас обводку надо включить а потом выключить?
🔸А цвет обводки?
🔸А если потом понадобится, чтобы обводка меняла паттерн или начинала мигать?

Под конец маленькие список потенциальных проблем, если пустить рендер часть на авось:
🔹Большое количество keyword'ов может привести к взрывному росту комбинаторной сложности.
Это значит — сотни тысяч, миллионы вариантов шейдеров, что отразится в часах компиляции проекта и на размере финального билда
🔹 NaN'ы, +-Infinity роняют проект на проде ни чуть не реже, чем баги в обычных скриптах

И при реализации фичи, эти вопросы всё равно должен кто-то решить. И вполне возможно, что этим "кто-то" окажешься именно ты)

Пост подготовлен при поддержке и редактуре @shiko_q, спасибо😘
Специально для любимого чатика Unity CG Tech

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

Комиссия Apple Store снизится до 10%

Я плотно следил за судебным разбирательством между Apple и Epic Games

Тогда линия защиты Apple строилась на том, что мол "такие комиссии" у всех
А Epic Games настаивал на том Apple пользуется исключительным правом монополиста диктовать размер комиссии

Закончилось все тем что комиссия осталась на прежнем уровне - 30%, но суд разрешил встраивать сторонние магазины

Дело было 2 года назад, но для самых любопытных ссылка на моей yandex disk с материалами дела

Толи это дело послужило прецедентом, толи Tin Sweeney узнал что европейский союз (the EU) собирается вводить новые правила и вовремя подсуетился, хз. Вопрос яйца и курицы

Но как факт (источник), пока только для EU:
🔻 iOS-приложения в App Store будут платить сниженную комиссию в размере либо 10 %, либо 17 % при совершении сделок с цифровыми товарами и услугами.
🔸 Плата за обработку платежей - приложения для iOS в App Store могут использовать обработку платежей App Store за дополнительную плату в размере 3 процентов.
Разработчики могут использовать провайдера платежных услуг в своем приложении или направлять пользователей на свой веб-сайт для обработки платежей без дополнительной платы Apple.
🔸 Будет добавлен Technical Fee
Приложения для iOS, распространяемые в App Store и/или на альтернативном рынке приложений,
will pay €0.50 for each first annual install per year over a 1 million threshold. расшифровать однозначно это пока сложно.
Но как я понял за каждую установку свыше 1кк в год, платишь 0.5$

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

Какое дело бизнесу:
🔹 Бизнес, как и всегда, адаптируется
С учётом того, что есть опция "оставить как раньше"
🔹 Разница комиссий останется в карманах бизнеса.
Может положительно сказаться на качестве, кол-ве игровых проектов

Какое дело до этого разрабам:
🔸 Да никакого, просто инфа похаливарить в чатах

Но самое крутое:
🔻Теперь официально можно принимать оплату И устанавливать игры на устройства Apple через сторонние магазины и сервисы

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

Ждем изменений со стороны Google, Valve, Sony, Nintendo и других платформ цифровой дистрибуции

В интересное время живем, крутые изменения
А вы что думаете? Пишите в комменты 🥰

@UniArchitect

UnityEngine.Object == null

Мне не так давно написал один из разработчиков на проекте, который столкнулся с проблемой зомби объектов.

Зомби объект — жив потому что GC не может его собрать, так как в стэке есть ссылка на него, но сам объект уже Destroyed.

И дело тут не в том, что GC.Collect еще не вызвался, а в том что мы храним указатель на объект, который уже уничтожен.

Такую ситуацию очень легко получить:
🔹Берем любой класс наследник MonoBehaviour
🔹 Реализуем в нем любой интерфейс
🔹 Instantiate'им объект, сохраняем в переменную
🔹 Во вторую переменную cast'им наш объект к интерфейсу
🔹 Уничтожаем MonoBehaviour
Через Object.Destroy или Object.DestroyImmediate
🔹 Пытаемся вызвать поле или метод интерфейса

Вопросы:
🔸 Будет ли MonoBehaviour == null?
🔸 Будет ли переменная интерфейса == null?
🔸 Будет ли ошибка при вызове любого member'а интерфейса?

Подсказка

Ответы:
👍 Да
👎 Нет
❓ И да и нет.
Если вызваемый мембер не часть MonoBehavior имплементации - ошибки не будет
В остальных случаях будет MissingReferenceException

Почему так?
Потому что любой UnityEngine.Object имеет 2 runtime части:
🔹Одна на стороне unity (написанная на C++)
🔹Вторая на стороне CLR (Common Language Runtime) — класс/структура C#

Это значит:
🔸 CLRObject может смотреть уже на уничтоженный UnityObject ровно столько, сколько мы храним указатель на него
🔸 Если UnityObject уничтожен, мы все еще можем обратиться к его CLR части и взять оттуда любые данные, которые не является частью UnityObject
🔸 Момент сборки данного объекта GC может быть отложен на сколько угодно по времени

Это ведет к проблемам:
♦️ Утечки памяти по всему проекту.
UnityObject уничтожен и нам нужно удалить объект из коллекции, а мы не можем, потому что interface != null
♦️MissingReferenceException, в неожиданных местах со вкусом фрустрации и сложной отладки

4 возможных решения:
1️⃣ Проверять все экземпляры типа интерфейса методом:

bool IsNullUniversal<T>(T instance)
{
  if (instance is UnityEngine.Object unityObject)
    return unityObject == null;

  return instance == null;
}

2️⃣ Для абстракции ВСЕХ монобехов использовать только abstract классы
3️⃣ Наследовать все интерфейсы от IEquatable<T> и использовать везде метод Equals вместо ==
4️⃣ (самый быстрый, самый дерзкий)
Через UnsafeUtility читать m_CachedPtr и m_InstanceID и через рефлексию дергать метод DoesObjectWithInstanceIDExist
Вот как это примерно может выглядеть

Почему именно так:
🔸UnityObject содержит перегрузку оператора == и != которая проверят что нативная (C++ часть) "жива"
🔻Но в CLR части == транслируется в операцию seq, которая в после IL2CPP будет выглядеть так:

((((RuntimeObject*)instance) == ((RuntimeObject*)NULL))? 1 : 0)

Или проще говоря в обычное сравнение 2ух указателей.

Такой проверки в случае реализации интерфейса в UnityObject не достаточно.
Потому мы получаем false-negative результат при сравнение на null, который потенциально ведет к утечкам памяти

Я создал Gist в котором расписал подробно TestCase'ы и решение.
Не стесняйтесь его дополнить или предложить свой вариант в комментариях 😎

#будни@UniArchitect

KISS, SOLID, YAGNY, DRY

И почему я про них не хочу писать.

Однажды в X один чел запостил прикольный пост, который объясняет бесполезность 99% всего интернет-срачей

Вот смотрите, есть исследование, которое гласит что в космосе между Марсом и Юпитером есть чайник

Ваша задача это опровергнуть, го в комменты, я создал 👨‍💻

Вот чушь ведь, но мы не сможем опровергнуть это.

Вот так же подумал чувак и описал один простой закон, его даже в Nature цитировали, лол:

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

Признавайтесь, кто распознал Чайник Рассела? 😅

Я 5 раз садился писать статью про KISS, как и обещал в посте про Cognitive Complexity, но нужно просто неимоверное кол-во усилий чтобы доказать абсурдность того, что написал когда-то вояка из VMware.

Кстати есть один хороший инструмент, который используют философы:

Бритва — инструмент, помогающий отбрасывать (сбривать) маловероятные, неправдоподобные объяснения.

Есть пара бритв:

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

Моя любимая:

Бритва Хэнлона — никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью

Главное Хэнлона ненатягивать на все подряд, а то окажется что весь мир построен на глупости 😅

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

Бремя доказательства оставляю за читателями в комментах 😬

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

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

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

А пока я разбираю работы Wang'a и думаю как весь этот годный материал скомпоновать в статьи

Ставь 👍 если ты за такую движуху и контент!

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

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

Сейчас активно перерабатываю большое кол-во материала по архитектуре.

И решил начать с основ, то откуда все берет свое начало - способы измерения сложности ПО.

В первой части, я попытался сделать выжимку статьи Yingxu Wang'а про Cognitive Complexity
Кто пропустил, крайне рекомендую

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

В общем, ниже будет вопрос, ответьте на него про себя честно

Вопрос:
С чем вы испытываете большую сложность в понимании?
1️⃣ Большой класс (модуль) с несколькими вложенными циклами, делающий сложные мат вычисления, например преобразование координат
2️⃣ Маленький модуль с множеством подклассов, которые этот класс вызывает в зависимости от входных данных.
И наличие длинных цепочек взаимосвязанных операций внутри.

Договоримся что оба модуля являются реализацией одной и той же логики внутри.

Ответ:
Согласно выводам из когнитивной информатики (cognitive informatics): Людям проще дается большие циклы итераций, однако люди не очень хорошо справляются с функциональной сложностью (длинная цепочка связей, высокая абстракция объектов)

Цитата:

For instance, according to cognitive informatics (Wang, 2002b, 2003a, 2007b),
human beings may comprehend a large loop of iteration, which is the major issue of computational complexity, by looking at only the beginning and termination conditions, and one
or a few arbitrary internal loops on the basis of inductive inferences. However, humans are not
good at dealing with functional complexities such as a long chain of interrelated operations,
very abstract data objects, and their consistency maintenance.
TAXONOMY OF SOFTWARE COMPLEXITIES IN COMPUTING AND SOFTWARE ENGINEERING, p.4

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

Кстати, в первую часть я не включил этот пункт, т.к. посчитал его достаточно очевидным:
🔸O(N) — вычислительная сложность (time complexity) не влияет на когнитивную сложность.
Аналогично для space complexity

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

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

Ставь 👍 если ты за такую движуху и контент!

#software_engineering@UniArchitect

ПРОТИВ ВЫГОРАНИЯ

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

После случился Silverfox, а там и переезд в Испанию.
В общем не до отдыха было.
Только стресс, только хардкор

И вот наконец-то в этом году запланировав заранее и четко решив что 3 год без лыж я не протяну, решил с семьей и друзьями поехать в Гудаури, Грузия 🥰

Я фанат лыж, с 4 лет на них стою.
Родился я рядом с Шерегешем (Геш) и застал еще времена, когда там не было даже зеленой креселки (шории), а была только пара бугелей до самой вершины основного спуска.

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

Даже забавная история есть:

Январь, Вторник, на улице -33
Звоним в школу, говорят не приходить
Не долго думая, батя говорит:
— А давай в Аквилон (когда-то любимая гостиница в Геше) звякнем, спросим скок там? Если меньше чем дома, поедем покатаем!
... через 5 минут
— Лех, погнали греться, в Геше всего -17 🤣
И вот, с чувством что мы наебали систему мы довольные поехали 😎
Но на подъезде мы почуяли что неладное.
Градусник на всем маршруте выше -30 не понимался

Заехав в поселок мы увидели заветные -35 😐
Расстроившись мы с батей просто поехали домой

Ага, напугали ежа голой жопой сибиряка морозом, так и катали в 2 подштанниках, двух кофтах, замазаные звездочкой в -30 вдвоем на всей горе 😜
Работали ток бугели и Шория 🫡

У меня есть пост про выгорание.
Я и сам 2 раза выгорал.

Но в этом году я хочу отдыхать каждые 2-3 месяца по 5-10 рабочих дней.
С учетом выходных этого в аккурат хватает чтобы успеть переключиться и отдохнуть.

Это мой work-life balance.
Мне проще работать какое-то время на около максимальной продуктивности, а потом переключаться и с экстримом отдыхать.

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

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

А если вдруг кто с 24 по 1ое в Гудаури, пишите в личку, встретимся, покатаем, тяпнем по пивку, обсудим архитектуру ПО 😊

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

Го пофлудим про отпуск и кто как отдыхает, жду в комментах)

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

ПРОКЛЯТИЕ ЗНАНИЙ

"Ну и говнокод, я бы сделал по другому!"

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

Так же как и матерый профессор в универе забывает с какими трудностями сталкивается студент при обучении.
Тем самым подавая материал с позиции "Ну это же очевидно"

Так же и "нам очевидно" какую задачу мы ставим себе в to-do list в Январе.
И не очевидно, когда мы возвращаемся к этой задаче через N месяцев.

🔺Все эти примеры к тому что это часть одного и того же явления, описанное и исследованное еще в 1989 году.

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

Нам сложно понять какие задачи мы занесли в to-do list, потому что мы менее информированы сейчас, чем в прошлом.

Нам сложно понять примеры профессора в универе будучи студентом. Или senior'a, будучи junior'ом.
Потому что объем знаний и опыта на их стороне. Они могут рассуждать, рассказывать о проблемах используя более высокий уровень абстракции и обширный словарный запас

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

При работе это может приводить к:
🔸Чрезмерному усложнению/графоманству при написании документации
🔸Бесполезными комментариям в коде и сложным названиям файлов/папок и классов HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor
🔸Уровень абстракции может быть слишком высокий
🔸Реализация/архитектура может быть переусложнена

И что самое интересное, что откликается во мне и на что я не обращал внимание:
🔻 Любой эксперт в своей инженерной области склонен усложнять систему в поисках доказательств своих знаний.
Т.е. мы заведомо экспериментируем, делаем системы сложнее, описываем документацию наиболее подробно, чтобы подтвердить, закрепить свои знания.

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

Из этого вывод:
❌ Не будьте авгуром, не утилизируйте свою сноровку в соображения о своем профессионализме 🤣
✅ Используйте свои профессиональные навыки и насмотренность для упрощения, не усложнения

Пара простых рекомендаций к практике:
🔹Простота документации важнее ее исчерпанности
🔹Простота понимания кода важнее абстракций и "масштабируемости"
🔹Суть и понимание диалога важнее используемых терминов

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

Я стараюсь писать свои статьи максимально просто, используя и перерабатывая сложную базу.
Дайте обратную связь в комментах ❤️‍🔥:
— Прокляты ли мои статьи?
— Сложно ли это читать/воспринимать?
— Удается ли мне выдерживать баланс между сложностью и интересом? Насколько для вас это важно?

Ставьте 👍 если такой контент заходит

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

ПРОДУКТИВНОСТЬ

Есть отдельный фетиш у программистов - фокусировка на личной продуктивности.

Например:
— Запоминаем все hotkey'и в IDE или переходим на vim
— Набираем вслепую 400 символов в минуту, перешли с qwerty на colemak даже
— Настраиваем систему под себя, не используем мышку

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

Или проще говоря, мы склонны полагать:

John Carmack крутой, потому что он гений, а все гении продуктивны.
Но не то, что он работал вместе с John Romero, а начало его карьеры пришлось на рассвет ПК 😬

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

По выводам из когнитивной информатики (данный раздел науки отвечает за изучение связи разработки и работы мозга):

1️⃣ Продуктивность ограничена физиологическим ограничением на скорость роста синаптических связей в мозге.
2️⃣ Прежде чем любая программа будет реализована, мы должны создать абстрактную модель у себя в голове.
3️⃣ Скорость создания абстрактной модели зависит от сложности, абстрактности, имеющихся знаний и опыта и индивидуальной особенности работы мозга.

Цитата:

Conservative productivity states that software productivity is physiologically constrained by the growing speed of synaptic connections inside the brain, because before any creative artifact is generated externally, it must be created and represented physiologically inside the brain by the synaptic connections.
Software Engineering Foundations, p37, 1.3.3.2, Yingxu Wang, 2017

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

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

Вы знаете, кому отправить этот пост 🛞

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

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

ПРИЧИНА И СЛЕДСТВИЕ

Я уже упоминал в своей истории что я самоучка.

Несколько фактов:
— У меня никогда не было наставника/коуча. Ток друг из интерпрайза, с которым можно перетереть за ITшку.
— Я всегда был вне IT тусовок.
Только хакатоны на начале карьеры, но знакомств результативных я оттуда не выносил
— С 2015 года всю информацию я черпаю только из книг, интернета и анализа реального опыта

За 9 лет пришлось переработать огромное кол-во информации.Обособиться, сформировать свое видение:
❕Cамообразование это игра в долгую. Это как бежать ультра-марафон. Нужно всегда помнить зачем, почему ты это делаешь.

И когда ты долго над чем-то одним работаешь, без целей никуда, потому я начинал с такого:
🔸 Мне нужно обогнать среднестатистического выпускника ВУЗа — нужно найти работу
🔸 Нужно получить исчерпывающий ответ на вопрос: "Как создаются игры в реальности?" — нужно руководить разработкой проекта
🔸 Для максимально быстрого роста, нужно забраться туда, где мне дадут больше, чем я способен унести — стать lead'ом, когда по факту middle

Это я так для себя в 2015 решил, как мне с нуля без знакомств, из сибирской глубинки в Москве, начать зарабатывать как можно больше.

При том для меня было важно:
🔹 Никаких подработок и распылений
🔹 Быть уверенным в том, что мои знания/навыки нужны и я не потрачу N лет впустую
🔹 Нужно получать максимально качественные знания

Долго анализируя то, что есть в информационном пространстве, я заметил такие особенности:
🔸Информации много, но качество низкое
🔸Даже если есть качественная информация, чаще всего ее сложно перепроверить самому
🔸Когда информацию можно проверить, часто она расходится

И по опыту изучения и осознания такого объема информации за 9 лет я сформировал главный, краеугольный принцип для себя:
🔻 Избегать следствия и работать только с причиной.

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

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

Этот принцип лежит и в основе этого блога.

Например посты:
▫️Когнитивная сложность ч.1
▫️Когнитивная сложность ч.2
▫️Проклятие знаний
▫️Продуктивность

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

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

Это всю эту информацию планирую сформировать в качественные стримы и курсы для людей, кто уже не вращает кубы 😬

Чтобы у всех у нас была качественная основа для принятия решений на реальных проектах.
Win-win так сказать 😊

Ставь 👍 если разделяешь и ценишь такой подход

Или может я совсем загнался и надумал все себе, напишите в комменты 📞

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

РЕЛИЗ FastMigrations.Json.Net

10 месяцев назад я написал пост про версионирование приложения:
ВЕРСИОНИРОВАНИЕ Ч.1
ВЕРСИОНИРОВАНИЕ Ч.2

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

Многие из вас следили за разработкой в режиме реального времени у меня на стримах
👉Ссылка на плейлист👈
(есть субтитры на английском, так что смело закидывайте европейским коллегам 😅)

По итогу, слово сдержал, пользуйтесь на здоровье ❤️
https://github.com/vangogih/FastMigrations.Json.Net
Жмакайте на ⭐️, чтобы не потерять!
Версия 1.0.3 — production ready, можно смело внедрять к себе в проекты 💪

🔻Что изменилось за кадром:
🔸 Сделал CI на github actions, который прогоняет тесты на 5 версиях unity
🔸 Для тестов включил вычисление test coverage и задеплоил результаты на github pages
Кликните на бейджик Coverage, чтобы понять о чем это я 😜
🔸 Сделал отдельную сборку для benchmark'а
Просто чтобы понимать на сколько быстрее. Так-то в 5-7 раз!
🔸 Сгенерил через всемогущий ИИ иконку
Вот оно где будущее, когда прогеры могут нормальный логотипы для своих плагинов делать😂
🔸 Опубликовал плагин в nuget и openupm
🔸 Написал и оформил лучшее readme в своей жизни 🥺

Достаточно много осталось за кадром, но поверьте, по большей части там была монотонная работа, где я 95% залипал в документацию.
Ибо с github actions, pages я работал впервые

🔻Что я лично для себя понял про подобного формата работу:
🔹 Нужно иметь выдержку и самодисциплину
Честно, если бы я не пообещал и не начал всю эту активность со стримами, мне было бы сложно сохранить достаточный уровень мотивации чтобы закончить работу над плагином
🔹 Качественная упаковка open source плагина занимает около 50% времени от самой реализации
Я понимаю что плагин не большой, всего 400 строк кода, но я явно недооценил сколько времени уйдет на оформление, CI/CD и документацию
🔹 Дисциплина кода, коммитов, архитектура даже для маленьких проектов важна
Иначе чтобы сделать нормальный CI/CD без боли, придется перелопатить половину проекта

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

А до этого момента продолжу делиться инсайтами по разработке и архитектуре unity проектов!

Всем огромное спасибо, без вас этого плагина не было бы 😘

Кстати, в репозитории есть открытые Issue, ошибки в readme и xml-doc'ах
Не стесняйтесь внести свой вклад и стать contributor'ом 🫡

@UniArchitect

МЫ ИНЖЕНЕРЫ, НЕ ХУДОЖНИКИ

🔹 Разработка ПО не имеет теоретической базы, как математика например
🔹 Разработка ПО это не инженерная дисциплина, скорее творческая, как живопись
🔹 Каждый может программировать. Дети иногда даже лучше чем взрослые
🔹 Каждый кто смог вывести в консоль "Hello World" может быть уверен в том, что он/она программист

Каждый кто согласен хоть с одним утверждением выше, скорее всего не имел дело с достаточно объемными программами (проектами) от 5000 до 10000 строк (LOC - Lines Of Code) в размере.
Это эквивалентно книге в которой 100 страниц это код на ЯП высокого уровня и документацией.
И это лишь минимальный порог, когда мы можем считать программу достаточно сложной.

Wang, Software Engineering Foundations, p.13

Средняя игра на soft launch этапе, примерно с неделей геймплея имеет размер около 60-100к строк кода.

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

Работа в таких проектах без стандартов, систем, принципов, передовых практик просто не возможна.
Потому что ведет к неуправляемому росту сложности и как следствие — к невозможности контролировать сроки. А это 40% почему проекты терпят неудачу.

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

Сколько утверждений выше согласуется с тем, что вы делали будучи программистом?

Отсюда выводы:
🔹 Разработка ПО — инженерная дисциплина, а разработчики ПО инженеры, не художники 😅
🔹 Заблуждение выше возникло из-за непонимания того, что делает и какие проблемы решает программист
🔹 Потенциальное решение проблем при разработке может лежать в плоскости других инженерных дисциплин

И есть раздел, рассматривающий разработку ПО как инженерную дисциплину:

Software engineering (SE) — инженерная дисциплина, которая изучает природу ПО, подходы и методологии крупной разработки, а так же теории и законы, лежащие в основе поведения ПО и практики разработки ПО.
Wang, Software Engineering Foundations, p.23, definition 1.6

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

Ставь 👍 если тебе нравится такая движуха

#software_engineering@UniArchitect

👀🗑Сборка мусора в Unity? Путь GC.Collect().

Давайте проследим некоторый путь. Путь GC.Collect(). Но сначала.
Что такое GC.Collect()? Это принудительный вызов сборки мусора.

Во что превращается GC.Collect? Ведь мы знаем, что Unity использует другой сборщик, который называется Boehm GC, а следовательно GC.Collect должен во что-то транслироваться.
Чтобы ответить на этот вопрос, нужно проследить путь преобразования кода.

1️⃣ Давайте напишем простой класс (Убираю лишние переносы в целях экономии места в посте; Длинные имена, сокращены для простоты чтения ):

public class Minutri : MonoBehaviour {
    private void Start() {
        GC.Collect();
        GC.Collect(2, GCCollectionMode.Forced);
    }
}

Два разных вызова — чтобы посмотреть, куда уходит двойка, а куда GCCollectionMode.Forced. GC.Collect(2, GCCollectionMode.Forced) говорит о том, что нужно вызвать сборку вплоть до второго поколения с forced. Но не забываем — мы работаем с Boehm GC. Поэтому про работу с поколениями не может идти речи. Как же получается? Написать так можно — а поколений нет. Смотрите далее)

2️⃣ После трансляции IL2CPP находим метод Start класса Minutri. Называется он у меня Minutri_Start_...

3️⃣ В Assembly-CSharp.cpp наблюдаю, во что превратился метод:

void Minutri_Start_ (Minutri_t* __this, ) {
static bool s_Il2CppMethodInitialized; // <------ а
GC_Collect_m(NULL); // <------ б
GC_Collect_m(2, 1, NULL);
return;

Интересовать нас может сразу два пункта:
а) Видим использование static bool. Напоминаю — это медленно.
б) Оба метода GC_Collect раскрылись, мы их наблюдаем, и они похожи.

4️⃣ Идем глубже, в методы GC_Collect_m...

void GC_Collect_m() {
static bool s_Il2CppMethodInitialized;
L_0 = GC_get_MaxGeneration_m(NULL);
GC_InternalCollect_m(L_0, NULL);
}

а) Опять static bool.
б) Воу 🤨 Все-таки получаем максимальное поколение. Получается, я вам врал! Какой ужас. (нет)
в) Вызываем GC_InternalCollect_m и передаем туда "максимальное поколение".

Давайте я вам помогу, и мы не будем заходить в GC_get_MaxGeneration_m. Он возвращает ноль. Но это и неважно. Сейчас все увидите.

5️⃣ Зайдем глубже, в GC_InternalCollect_m. Мы видим метод. Там опять нам всё не нужно, кроме одной строки:

(()mscorlib::System::GC::InternalCollect) (___0_generation);

Заходим в InternalCollect. Далее в Collect(generation)

6️⃣ Ну что ж. Мы пришли, поздравляю!) Метод Collect перед вами целиком:

void il2cpp::gc::GarbageCollector::Collect(int maxGeneration) {
#if IL2CPP_ENABLE_DEFERRED_GC
    if (GC_is_disabled())
        s_PendingGC = true;
#endif
    GC_gcollect();
}

Тут, как мы видим, всё: последнее упоминание поколений. Глубже мы не пойдем.
Вы видите, чтобы maxGeneration параметр где-то использовался? Вот и я не вижу.
Зачем они так сделали? Вероятней всего для того, чтобы в случае использования другого GC можно было быстро перейти на поколения.

Так, а что у нас с GC.Collect(2, GCCollectionMode.Forced)?
Там пойдут goto и прочие вещи, которые здесь не буду рассматривать, так как не хватит места в посте. Но, короче говоря: в нем будет вызов этого же Collect из пункта 6️⃣. То есть, что бы мы ни указывали в аргументы GC.Collect — это не имеет значения.

Резюмируем:
— GC в .NET C# поколенческий, в Unity - нет
— Вызов сборки мусора конкретного поколения вызывает сборку мусора в целом
— Перегрузки GC.Collect, при настройке билда в IL2CPP не влияют на перформанс и ничего не ломают

P.S. Может быть я был не прав, и мы посмотрели что-то неверно? Давайте, как люди, которые хотят докопаться до сути, обратимся к первоисточнику, и посмотрим на ответ Josh Peterson'а. В ходе диалога, я задал вопрос о том, используют ли юнитеки поколения в Boehm? Был дан ответ:

"Currently Unity does not use the generational GC in Boehm. I suspect that we might be able to use it, but we don't have any active plans to enable that for now".

Анализ трансляции GC.Collect подготовлен специально для @UniArchitect

Об устройстве GC в Unity, о IL2CPP, CI/CD и не только я пишу в своем авторском telegram канале. Подпишись!🔥

ПОЛИМОРФИЗМ СИСТЕМЫ

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

Давайте представим. У вас есть любой язык программирования. Что вы на нем НЕ сможете написать?

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

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

🔹Давайте порассуждаем глобально, без привязки к языку/платформе.
Для простоты возьмем самую примитивную задачу: "Вывод Hello World на экран".
Сколько вариантов решений вам приходит в голову?
Мне из-за проклятия знаний даже сложно представить, сколько их. Потому мой ответ: а какие ограничения?

🔸Этим всем. Я подвожу к мысли:

У любой задачи несколько решений. И мы, анализируя внешние факторы и время, склонны выбирать наиболее эффективное в данный момент.

Назовем это полем решений S (solutions).

🔸Любое решение можно проектировать по разному. При том вариантов дизайна может быть сколько угодно.
Назовем это поле вариантов дизайна D (design).

Например:
— Под каждый char заведем свой класс. Сделаем fluent builder, который будет собирать нашу строку посимвольно.

🔸Ну и наконец у каждого решения есть поле реализаций (имплементаций). То как эта задача может быть фактически написана.
Назовем это — I (Implementation).

Пример:
— Каждый char представим в виде ASCII кода, запишем в массив и при выводе сконвертируем коды в символы.
— Или напишем свой рендер символов в консоли

🔻Отсюда 1ый принцип инженерной разработки:

Каждая задача имеет поле возможных решений, которое является произведением поля возможных реализаций и поля возможных дизайнов.
-
Wang, Software Engineering Foundations, p.33, Theorem 1.6

В виде формулы это будет выглядеть так: S = D * I

Это подводит к вопросу, а насколько велики D, I и S?
— Много велики. Потому что (D * I) -> ∞.
А на поле решений влияют многие факторы, такие как:
— Выбранный ЯП.
— Code style.
— Модели данных.
— Маршалинг объектов в память.
Любое изменение будет приводить к другой(-му) реализации/дизайну решения.

🔻Из этого следует очень важный вывод, от которого болит у всех:

Трудно технически и/или экономически доказать что программа имеет единственно верное рациональное решение в поле возможных решений.
Это более известно как: не существует единственно верного решения
-
Wang, Software Engineering Foundations, p.33, Corollary 1.4

Это одно из фундаментальных ограничений, с которым мы имеем дело каждый день. А называется оно — полиморфизм системы.
И ограничение это когнитивное, т.к. завязано на фундаментальное ограничение человеческого мозга (про ПРОДУКТИВНОСТЬ я уже писал)

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

Вы знаете, кому отправить этот пост 🛞

Ставь 👍 если тебе нравится такая движуха

Ссылка на цитируемую книгу

#software_engineering@UniArchitect

ИНКАПСУЛЯЦИЯ

Кажется, у нас есть еще один претендент на звание "лучший повод развести холивар".

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

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

Инкапсуляция. Давайте просто посмотрим на определения:
🔹 Русскоязычная википедия.

процесс разделения элементов абстракций, определяющих её структуру (данные) и поведение (методы)

🔷 Англоязычная википедия.

объединение объекта и его метода с данными

🔹 Другой ресурс, тоже вики, специализирующийся на разработке ПО.

процесс объединения элементов для создания нового объекта

При том в научных статьях, книгах и блогах известных специалистов сохраняется точно такая же путаница:
🔸 Статья на которую ссылаются другие 23 статьи в которой:

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

🔸 Мартин Фаулер

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

🔸 Bertrand Meyer в книге Object-Oriented Software Construction вообще говорит что это синоним Information Hiding

Не обязательно ходить по всем перечисленным источникам. Я лишь хочу подсветить проблему:
🔻У нас НЕТ нормального/единого определения такого базового термина как инкапсуляция!

Т.е. при работе в команде, упоминая данный термин, вы должны держать в голове ворох расплывчатых определений, чтобы понять, что имеет в виду другой человек. Точно так же с чтением книг и статей.
Многие авторы, при этом, не чураются надумать себе какое-то 3 определение и найти тайный смысл.

Изучая, пробираясь через весь этот ворох, для себя я сделал пару выводы:
1️⃣ Каждый раз при упоминании данного термина, желательно уточнить у другого человека, что он имеет в виду.
2️⃣ Каждый раз, видя это термин в книге/статье, подбирать подходящее определение и пытаться понять, что хотел сказать автор 🤬
3️⃣ Я перестану употреблять этот термин. Чтобы не вводить никого в заблуждение.

Вместо него просто буду использовать синонимы, которые отлично отражают суть:
🔸 Модификаторы доступа, интерфейс, абстракция: в случае если хочу сказать про сокрытие/ограничение доступа
🔸 Представление объекта в памяти, виртуальная таблица, объединение методов и данных: для случаев, когда захочу описать особенности ОО языка

Ну и если я могу дать рекомендацию:
🔻 Держите в голове суть беседы, обсуждения, разговора, а не корректность терминов, когда говорите о разработке.

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

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

#аббревиатуры@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

С ПОЛЕЙ РАЗРАБОТКИ: 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