🎙 Софт скиллы для разработчика

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

💡 В отличие от хард скиллов, софт скиллы — это навыки общения, которые важны не только в работе, но и в жизни.

Вот ключевые навыки, которые мне особенно помогают:

🔹 Проактивность
Не жди, пока кто-то даст тебе задачу или укажет на проблему.
📌 Пример: Ты заметил, что билд стал дольше собираться после недавнего обновления. Вместо того чтобы ждать, пока кто-то начнёт жаловаться, ты сам анализируешь логи, находишь узкое место и предлагаешь решение на синке. Это сразу поднимает твой авторитет в команде.

🔹 Конструктивное решение конфликтов
Конфликты бывают даже в самых дружных командах. Главное — не ссориться, а решать.
📌 Пример: Тебе не нравится, что продакт добавляет фичу, которую нужно сделать еще вчера. Вместо того чтобы злиться, ты договариваешься с ним, что фича будут сделана, но после обязательно проведем рефакторинг этой фичи. Проблема решена, отношения не испорчены.

🔹 Умение просто объяснить сложное
Часто приходится доносить технические детали до нетехнических коллег.
📌 Пример: Продакт спрашивает, почему нельзя “просто сделать мультиплеер за неделю”. Вместо “это невозможно” ты говоришь: "Чтобы игроки могли подключаться друг к другу и видеть действия в реальном времени, нужно реализовать систему синхронизации и авторизации. Можно сделать ее за неделю с готовыми решениями, но все будующие фичи будут разрабатываться дольше"

🔹 Сфокусированность на результате
Важно не просто “делать задачи”, а помнить про конечную цель.
📌 Пример: ты заметил, что фича, над которой работает команда, не даст пользы без аналитики. Вместо того чтобы «просто сделать задачу», ты обсуждаешь с продактом и предлагаешь доработать ТЗ, добавив аналитику. В итоге — выкатили фичу, которая реально помогает принимать решения.

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

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

1. Дейл Карнеги — Как завоёвывать друзей и оказывать влияние на людей
Классика, которая учит слушать, говорить и вызывать симпатию.

2. Лейл Лаундес — Как говорить с кем угодно и о чём угодно
Более практическая книга, особенно полезна интровертам.

Мне действительно хочется больше говорить о софт скиллах, ведь они влияют на карьеру не меньше, чем ваш код.
Если тема вам интересна — поддержите пост реакцией ❤️ или комментарием. Тогда я подготовлю ещё пару разборов по конкретным ситуациям из жизни

🎮 Unity и WebGL

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

А пока хочу поделиться опытом, который мы обсуждаем в команде всё чаще: насколько Unity вообще подходит для WebGL-игр?
Если коротко — подходит, но с нюансами. Делюсь личным опытом и наблюдениями


💡 Начнём с плюсов, которые на поверхности:

🔹 Лёгкий порт с мобильных платформ
Скорее всего, если у вас уже есть мобильная игра — порт на WebGL займёт минимум времени

🔹 Кроссплатформенность
Вы пишете игру один раз, а она работает везде: браузер, мобилки, ПК

🔹 Богатая экосистема
Unity-ассеты, туториалы, плагины, CI/CD — всё уже есть и хорошо работает


💡 А теперь к менее очевидной части

🔻 1. Большой размер сборки

Unity WebGL часто критикуют за вес. Но это, скорее, вопрос оптимизации, а не движка.
У нас был кейс, где коммерческий билд весил меньше 10 МБ, а в минимальный вес — всего 3.5 МБ.
Так что при желании ужимается всё.

🔻 2. Высокое потребление ресурсов

Тут всё не так однозначно
Да, Unity собирает WebGL через WebAssembly — и теоретически он работает даже быстрее JavaScript
Но на практике узкое место это архитектура Unity которая делает вычисления и рендер каждый кадр, а не по событиям

Unity UI также негативно влияет и на память, ведь в Unity для интерфейса мы используем текстуры, которые по возможности заменяем на ассеты типо TrueShadow или ProceduralImage, но в любом случае в памяти даже самый оптимизированный UI будет занимать одназначно больше места чем CSS

Плюс Unity имеет некий минимальный размер в памяти, котоый на оптимизированном, пустом проекте составил около 45 МБ, что заставляет делать серьезные оптимизации, что бы влезть в лимит памяти для мобильных устройств

🔻 3. Ограниченный доступ к системным API

Работа с файлами, буфер обмена, интеграции с внешними JS-фичами — всё это требует ручной JS-интеграции через *.jslib.
Это несложно, но утомительно. Ассетов в Asset Store, которые закрывают эти задачи “из коробки”, пока мало.


🧠 Итог:

Unity подходит для WebGL, особенно если у вас:
— уже есть мобильная игра
— сложная логика, 3D и прочий “движковый” функционал

Но если ваша цель — быстрая и лёгкая браузерная игра с акцентом на UI, есть варианты попроще.

Если было полезно — ставьте ❤️ или напишите пару слов в комментарии!
А если ты вдруг читаешь это и не поставил лайк — возможно, ты уже отлично разбираешься в Unity WebGL.
В таком случае у нас есть вакансия Middle Unity-разработчика, который займётся портированием игр на WebGL. Пиши в личку: @romanchikov

💥Найдёте все 10 ошибок?

Недавно мне попался на глаза один кусок кода и, честно говоря, почти каждая строка попадает в раздел "Так делать не нужно"

Я насчитал как минимум 10 проблемных мест, которые точно стоит отнести к плохим практикам

А ты сможешь найти их все? Пиши в комментарии, что бы вы точно поменяли в этом коде

А в следующем посте:
Я расскажу, кто первым назвал больше всего правильных пунктов и подробно разберу каждую ошибку

🧠 Разбор кода: 10 ошибок из прошлого поста

Как и обещал — делаю разбор кода с прошлой публикации. Поехали!

Ошибка 1. GameManager
Название класса не информативное. Можно очень легко понять хорошее ли название класса, метода или переменной. Для этого достаточно посмотреть на название и не изучая код понять, за что отвечает эта сущность. Название GameManager означает, что внутри этого класса может быть все что угодно.

Ошибка 2 и 3

public static event Action OnCubeSpawned = delegate { };

2. Сам класс не является статическим или синглтоном (то есть быть в единственном экземпляре), при этом эвент статический. Статический эвент только в статических классах

3. = delegate { };
Получается мы создаем пустой делегат и всегда его вызываем, что не имеет смысла. Тем более в C# принято вызывать эвенты через ?.Invoke()

Ошибка 4 и 5

private void Awake()
{
    spawners = FindObjectsOfType<CubeSpawner>();
}

4. FindObjectsOfType<CubeSpawner>();
Ну тут наверное каждый разработчких схватился за сердце, когда увидел эту строчку. Во первых тут есть скрытая зависимость и нарушение принципа D (SOLID), во вторых это тяжелая операция

5. Еще одной ошибкой является вызов в Awake()
Не даром Unity сделала 2 метода инициализации: Awake и Start, и их условное различие в том, что Awake вызывается для инициализация внутренних компонентов скрипта, а Start для внешних. Если придерживаться этого правила, то можно будет избежать багов и проверок на инициализацию компонентов. Но лучше использовать DI

Ошибка 6, 7, 8

if (Input.GetButtonDown("Fire1"))
{
 ...
}

6. Лучше использовать конструкцию if-return

if (!Input.GetButtonDown("Fire1"))
    return;

Тогда код не поменяет свою логику, а код станет читабельнее

7. "Fire1" стоит вынести в константу и использовать ее, вместо конкретной строки

8. Input это отдельная ответственность, что нарушает принцип S (SOLID), такую логику нужно вынести в отдельный класс и добавить эвент на конкретное действие

Ошибка 9

currentSpawner = spawners[UnityEngine.Random.Range(0,2)];

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

Ошибка 10
Общий код стиль проекта отличается от Microsoft code convention
Отсутствие private, название полей без "_", отсутствие отступов, но, когда я провожу ревью, я обычно отношу эти недостатки к несущественным, так как можно довольно легко их исправить через код стиль райдера, например. Исключением является, пожалуй совсем уж странные подходы к форматированию кода, такие как венгерская нотация или форматирование через Tab как в шейдерах

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

P.S Спасибо всем, кто проявил активность в прошлом посту! А я уже дописываю пост про софт скилы

🎙Софт-скиллы разработчика

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

🥇Нацеленность на результат

Успех не меряется усилиями. Он меряется результатом

Я начал свой путь разработчика в МГТУ им. Баумана, где меня окружало множество талантливых ребят, которых без сомнения можно назвать технарями от мозга костей до кончиков пальцев. Во время нашего обучения у нас был предмет под названием "Основы экономики", на который ходило от силы 20% студентов, в числе которых был и я. Главным аргументом тех, кто пропускал пары, было то, что этот предмет нам не пригодится в будущем как специалистам. Я же считал и считаю иначе, потому что большинство из нас работает в коммерческих компаниях, главная задача которых зарабатывать деньги. Любой сотрудник такой компании это часть одного большого механизма. Весь наш труд направлен на то, чтобы компания заработала деньги, из которых нам выплатят зарплату. Из этого плавно вытекает моё первое правило: "Нацеленность на результат"

Давайте разберу ситуацию из собственного опыта

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

В 9 вечера мне позвонил менеджер на личный телефон и описал проблему. В тот момент я был на тренировке. Передо мной стоял выбор: бросить всё и срочно спасать ситуацию или ответить, что рабочий день закончился, и заняться этим завтра. Я выбрал первое, потому что руководствуюсь принципом "Нацеленность на результат"

Уже в 9:30 я сидел за компьютером, созвонился с менеджером, и мы провели на связи около восьми часов. К 5 утра мы залили билд с исправлением и попросили быструю модерацию у стора. Позже выяснилось, что проблема была на стороне бэкенда, и технически я не был виноват. Но вместо того чтобы "отмыться", я сделал всё, что мог и мы спасли проект от огромных финансовых потерь, а возможно, и от полной гибели

И это касается не только эпичных ситуаций, но и вполне бытовых

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

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

Команда QA провела тестирование в воскресенье, и в понедельник мы выпустили релиз, как и планировали
Поэтому правило: Нацеленность на результат прочно закрепилось в списке моих личных софт-скилов


💬 Говорите просто о сложном

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

Если бы мне платили доллар каждый раз, когда на синке разработчик говорит: "Да у нас в классе SerializationService сериализация бинарная, а не JSON"... А, стоп, погодите мне же за это и платят. Я же перевожу с технического на менеджерский

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

Представьте, что продакт однажды скажет:
«У нас есть валидированный юзер-фидбек, метрика drop rate по воронке просела на 12%, а фича уже behind по roadmap».
Вот именно так звучим мы, когда начинаем говорить "по-своему" со всей остальной командой


🤷‍♀️ Не будьте загадкой для своей команды

Сюрпризы для дней рождения, а не для команды

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

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

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

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

А если задачу всё-таки нужно успеть в срок за счёт качества кода, то сразу после релиза поставьте задачу на рефакторинг


👔 Менеджер всегда прав!

А если не прав — см. пункт выше

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

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

Пара примеров из практики:

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

А вот пример от моего друга и активного подписчика канала
(обращение к нему: если решишь закидать меня камнями, то лучше сделай это, пожалуйста, в каком-нибудь выживаче 😅)

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

Был ли прав тимлид, допустив такой код? — Нет
Был ли прав разработчик, что пришёл с претензией в такой форме? — Тоже нет
Потому что, как бы это ни звучало: менеджер всегда прав!

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


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

🎮 Найти работу Unity-разработчиком — всё ещё легко?

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

Очень часто слышу мнение, что главное умение мыслить и оффер будет в кармане
К сожалению, это уже не так

📉 Ещё 2–3 года назад:
✔️ Рынок был на стороне кандидатов
✔️ Геймдев активно рос
✔️ Найти работу было относительно легко

Сейчас всё иначе:
• Рост геймдева замедлился
• Количество кандидатов растёт (новое поколение подросло)
• Зарплаты не растут, а иногда даже падают

🧠 Моё мнение основано на практике: я участвую в найме и вижу, как всё меняется. У нас в компании высокие стандарты и мы оцениваем весь стек: от мобильных SDK и WebGL до шейдеров и мультиплеера. Несмотря на это, мы стабильно нанимаем кандидатов. Но цифры говорят сами за себя

📊 Наша статистика за 2025:

Senior-разработчики
🔹 150 приглашений
🔹 49 code review — 30%
🔹 22 HR-интервью — 15%
🔹 4 тех. интервью — 2.5%
🔹 3 интервью с CEO — 2%
🔹 2 оффера — 1.5%

Middle-разработчики
🔹 80 приглашений
🔹 41 code review — 50%
🔹 21 HR-интервью — 25%
🔹 9 тех. интервью — 11%
🔹 2 интервью с CEO — 2.5%
🔹 1 оффер — 1%

🛠 Вывод:
Просто “уметь разобраться” уже недостаточно.
Нужны:
✅ Уверенные технические навыки
✅ Готовность к собеседованиям
✅ Прокачанные софт-скиллы

💬 P.S.
Будет круто, если поделитесь в комментах своими историями прохождения/проведения собесов.
Согласны ли вы с моими выводами?

🎥 Закончили трейлер игры!

В посте короткая версия ролика, а полную можно посмотреть на YouTube:
👉 https://www.youtube.com/watch?v=aNXYZrx5AxI

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

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

Вся основа трейлера сделана в Unity, а уже на пост-продакшене добавили звук и несколько визуальных эффектов

Добавить в вишлист: https://store.steampowered.com/app/3833810/Bioneers

🎉 Bioneers набрал 2000 вишлистов с момента анонса!

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

Кого ищем:
1. Гейм-дизайнер от 3 лет опыта, с большой экспертизой в жанре автоматизации и играх типа Factorio.
2. Эксперта в биологии с глубокими знаниями и опытом, а также пониманием жанра автоматизации.
Подробности в личку: @romanchikov

💰 Реферальная программа:
Если вы знаете подходящего кандидата и он пройдет испытательный срок мы выплатим 300 USDT бонуса.

📊 Как мы собрали 2000 вишлистов:
1. Выпустили трейлер 3000 просмотров и ~150 вишлистов.
2. Один из наших подписчиков опубликовал пост на Reddit, который собрал ~400 вишлистов и попал в Best.
3. Несколько медиа из США подхватили новость и выложили её в Facebook, X, YouTube ~1000 вишлистов
4. Сделали пост в Discord сообщества похожей игры (не поддерживается разработчиком) ~100 вишлистов.
5. Остальные пришли из других источников.

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

⚡️ Быстро или качественно?

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

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

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

Вот подход, который помогает:
🔹 Декомпозировать задачи на подзадачи максимум по 4 часа.
🔹 Если задача рискованная или связана с изучением нового (например, интеграция SDK или обновление Unity), фиксируем время. Если время вышло, то обсуждаем или останавливаем выполнение.

Так мы заранее видим риски и снижаем вероятность выхода за сроки.

🚀 Тот же принцип применим и к проектам:
🔹Если это тест идеи: делаем быстро и дешево, чтобы проверить
🔹Если идея доказала жизнеспособность, то делаем качественно. Часто правильнее даже переписать проект с нуля, чем тянуть старый код.

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

📌 Вывод:
Если задача или проект рискованные и непонятные, то делаем быстро, минимизируем риски.
Если задача или проект понятные, то делаем качественно

3 качества сильного программиста

Где-то пол года назад я уже запланировал сделать пост, так как планировал выступить на соревнования по пауэрлифтингу и взять кандидата в масте спорта. Спойлер: Я взял КМС!

Итак какие же это качества:
1. Становая за 200
2. Жим за 100
3. Присед за 200

Ну а если вы далеки от силовых видов спорта, тогда есть запасной вариант 😀

Я бы хотел в этом посте подсветить именно софт скиллы разработчика, основываясь на своем опыте

1. Умение разобраться в новом подходе или технологии быстро

Я сейчас активно внедряю TDD поход в своих проектах. В играх такой подход очень редко используется, а автотесты остаются где-то на уровне пет проектов. Однако один из моих разработчиков не стал пытаться отговорить меня от этого подхода, а воспринял этот подход как вызов. Он самостоятельно изучил какие фреимворки можно добавить, что бы улучшить тестирование (NSubstitute, Fluent Assertions), самостоятельно добавил их и использует AI для более эффективного и быстрого написания тестов. Через несколько спринтов этот разработчик научился этому подходу и делает тесты лучше меня, и я полностью ему доверяю и знаю, что он сделает все хорошо.

2. Четко излагать идеи, задавать вопросы или отчитываться о результате

На одном из проектов у нас была довольно размытая задача. Нужно перенести проект из репозитория одной студии в репозиторий другой студии и настроить сборки. Это задачу невозможно оценить и она содержит много сложностей, которые узнаются в моменте и многие разработчики могли бы просто «ковыряться» неделями. Но один мой коллега сразу начал формулировать цели, разбивать их на задачи, подсвечивать риски и раз в день формировать отчет от проделанной работе и о планах на следующий день. Благодаря этому его работа была максимально прозрачна для всех и достаточно было 1 раз в день посмотреть на его отчет, что бы понять статус проекта

3. Структурировать и систематизировать хаотичную информацию

В одном из проектов я столкнулся с проблемой требования от клиента приходили фрагментарно, часть от одного человека, часть от другого. Что-то в устном виде, а что-то в переписке. Разработчики начинали путаться, терялись детали. Один из ребят взял на себя инициативу: начал собирать всё в единый документ, структурировал блоки требований, следил за главной целью. В итоге у нас появилась живая база знаний в одном месте, в которую можно было быстро заглянуть и понять, а что мы собственно делаем. Так мы смогли правильно спланировать и разбить задачи и построить процессы для заказчиков по формированию требований

🎯 Мой личный опыт использования AI-агентов

Я начал знакомство с AI-помощниками через Cursor IDE. Сейчас это, пожалуй, самая популярная IDE для vibe coding (написание кода с использованием AI).
Попробовал подключить его к Unity-проекту и даже использовать для менеджерских задач.
Но в итоге отказался от Cursor в пользу встроенных ассистентов в Rider и Visual Studio
да, не кидайтесь камнями. VS я использую для backend 😅


🧩 Кейс 1. Изменение существующей игровой механики

Я подключил cursor в существующий Unity проект - прототип мобильной игры и пробовал править механику сбора ресурсов через разные промты. Я пробовал настраивать MCP, запросы, контексты, правила, но результат получался такой, что мне было бы проще и быстрее сделать это самостоятельно

🧪 Кейс 2. Генерация автотестов по документации

Хотел построить процесс:
1. Проанализировать документацию в ClickUp (аналог Jira + Confluence);
2. На основе этого сгенерировать тест-кейсы и автотесты.

Как не пробовал я построить процесс генерации, но даже на этапе создания тест кейсов AI генерация показывала себя не очень хорошо

Честно говоря желания и времени разбираться с курсором больше не было и я решил забить на него, но попрбовать использовать очень похожую логику генерации AI агентов в Rider и Visual Studio


⚙️ Кейс 3. Генерация систем для Unity DOTS

Мой проект Bioneers использует DOTS как core-фреймворк.
Основное преимущество ECS в простой и понятной архитектуре. А значит, если в игре есть 20 систем, но написать 21 систему по похожей структуре можно без проблем, что я и решил попробовать сделать.

Для этого я использовал плагин Copilot для Rider и попробовал через него сгенерировать систему и это сработало!
AI агент сгенерировал систему, которая на 80% совпадала с тем, что мне нужно. Я вручную поправил остальные 20% и все, система готова. Я думаю я сделал такую систему в 2-3 раза быстрее чем, если бы писал сам в нуля с ChatGPT

Дополнительно отмечу, что мои навыки DOTS уже устарели (Дед уже, как ни как) и с помощью AI агента и сгенерированного кода я очень быстро разбираюсь в новой системе DOTS.


🌐 Кейс 4. Генерация запросов на сервере и клиенте

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

Я пробовал генераровать endpoint в Visual Studio + Copilot и сначала пришлось делать много правок, но где-то после 10 запросов качество сильно вырасло. AI agent генерировал код, который на 95% соответствовал тому, что я ожидал


💡 Вывод

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

Поделитесь своим опытом применения AI агентов в работе. Тема очень интересная! 💬

🎯 Личные хаки для продуктивной работы

Я работаю по 6 дней в неделю минимум по 12 часов каждый день. Работа, Bioneers, бытовые вопросы типо виз и другие дела, которые вынуждают меня работать так много времени.

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

⸻

Хак 1. Малайзия

Да, это звучит неожиданно, но страна сама стала моим продуктивным бустером.
Я живу в Малайзии, и это лучшая страна для жизни по соотношению цена–качество. Вот вам пример: я сдаю свою квартиру 46 метров в Москве, и это покрывает почти 80% моей квартиры в Малайзии. Только в Москве у меня 46 метров, а в Малайзии — 146!

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

Из дополнительных плюсов Малайзии: очень быстрый интернет, начало работы в 14:00 по локальному времени, высокий уровень бытового комфорта за копейки. А за 2000р в день наша помощница по дому делает уборку и готовит еду на 2 дня вперед.

Если вам интересно больше узнать о Малайзии, то моя жена начала вести блог про Малайзию и путешествия

⸻

Хак 2. Подъёмный стол

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

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

⸻

Хак 3. Дорожка для ходьбы

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

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

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

В общем, я прям рекомендую для тех, кто много работает.

⸻

Хак 4. Активно используйте Google Calendar

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

Также Google Calendar позволяет разделить обязательные дела от других. Среди обязательных можно выделить: созвоны, запуск сборок, важные задачи. Для всех таких событий я завожу событие в календаре.

Моё главное правило: если в календаре есть событие, то я обязан выполнить его в это время.

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

Это моя личная цифровая адаптация принципа bullet journal

⸻

Хак 5. Макросы

Автоматизируйте всё, что только можете. Я использую для этого Stream Deck и программу Raycast.

С помощью Stream Deck я могу в один клик поставить сборку, открыть сайт или создать MR.

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

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

Требуется Junior QA в команду Bioneers

Чуть больше полугода назад в команде Bioneers был только я. Сейчас нас уже восемь человек, и мы ищем девятого участника команды - Junior QA специалиста. С ума сойти, как быстро мы растём!

Проект находится в стадии активной разработки, и финансирование команды в основном идет от меня, поэтому вопрос оплаты для меня критичен.
Я могу предложить 20 000 – 30 000 рублей за ~20 часов работы в неделю.

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

⸻

Требования к Junior QA для Unity-игр
1. Завершённые курсы тестировщика игр или аналог, подтверждающий знания.
2. Понимание принципов ручного тестирования игр.
3. Навыки базового баланс-тестирования.
4. Минимальные знания нагрузочного тестирования.
5. Наличие ПК на Windows.
6. Умение составлять баг-репорты и тест-кейсы.
7. Умение работать с любым таск-трекером (Jira / YouTrack / Trello и др.).
8. Внимательность, организованность, ответственность, желание обучаться.

⸻

Что предстоит делать
1. Тестировать игровые фичи: проверять новые сборки на соответствие требованиям и визуалу.
2. Заводить баг-репорты по установленной форме.
3. Писать тест-кейсы на разные игровые механики.
4. Проверять игровой баланс.
5. Проводить регрессионное и smoke-тестирование релизных билдов.
6. Участвовать в ежедневных созвонах, а также в обсуждениях новых фичей.

⸻

По всем вопросом и предложениям можно писать в треде или мне лично @romanchikov

🧩 Хаос в задачах и сила Definition of Done

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

Вот типичные примеры:
* Делать несколько задач параллельно вместо того, чтобы закрывать их последовательно
* Писать код “на будущее”, добавляя лишние абстракции и параметры
* Начинать задачу с неполным ТЗ
* Зависать на бесконечном ресёрче
* Лезть в рефакторинг до того, как вообще есть что рефачить

И самое интересное — у всех этих проблем одна причина и одно решение.

🎯 Простое правило

"Закрывай Definition of Done как можно быстрее"

Чтобы это сделать, нужен правильный процесс. Любая задача состоит из четырёх этапов:
1. Погружение в контекст
2. Составление Definition of Done (DoD) — чёткие условия, при которых задача считается выполненной
3. Реализация задачи так, чтобы выполнить DoD
4. Рефакторинг и приведение кода в порядок (после выполнения DoD, а не до!)

Цель всегда одна — как можно быстрее выполнить DoD, а всё остальное — вторично.

⸻

📌 Разберём несколько кейсов

🔹 Параллельная работа над задачами

Например, разработчик делает “Профиль игрока” и понимает, что нужна “Система сохранений”. Из-за соблазна делать всё сразу обе задачи уходят в работу. За второй задачей подтягивается третья и вот в In Progress половина задач из спринта, сроки расползаются, непонятно чем человек занят на самом деле

Как быть?

Если реализация сохранений не нужна для выполнения DoD по профилю,
то просто сделайте интерфейс и мок-методы.
А полноценную реализацию — в отдельную задачу.

Так мы сохраняем фокус и не расползаемся в стороны.

Опять же. Думайте как закрыть Dod как можно быстрее

⸻

🔹 Начало задачи без понятого ТЗ

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

Задача без чёткого ТЗ = гарантированный хаос.

⸻

🔹 Рефакторинг “пока делаю фичу”

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

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

Рефакторинг всегда должен быть отдельной задачей с конкретным DoD.
Не частью другой задачи, а именно отдельной задачей

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

⸻

✔️ Итог

Правило "Закрывай Definition of Done как можно быстрее"
• даёт прозрачность
• ускоряет разработку
• снижает количество переделок
• уменьшает хаос
• делает команду быстрее и спокойнее

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