Мой дебют на Хабре прошел с максимально "успешно"
Карма понижена до -2, а рейнтинг понижен до -6

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

Я перевел статью в режим черновика и она будет временно не доступна до тех пор, пока я не сделаю работу над ошибками

Отредактировал статью и сделал ее публичной
Как пройти собеседование на Unity-разработчика: мнение лида

Основный контент и смысл остался тот же. Я не менял советы или важные пункты
Что поменял:
* Добавил пояснение и ремарки к некоторым пунктам, которые вызвали вопросы
* Сильно дополнил процесс связанный с Live coding, добавил больше деталей и нюансов. Постарался ответить на вопрос, почему 2 часа это нормально
* Добавил часть P.S. для тех, кто мог не правильно понять мой основный посыл

Пойду ставить свечку за мой рейтинг!

🎮 Что должен уметь разработчик игр?

💬 Ответ: то, что требует от него компания

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

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


Я работаю лидом в аутсорсинговой и аутстафинговой компании, специализирующейся на разработке игр в Unity. Наши проекты — от прототипов до сложных мультиплеерных игр на этапе liveops. В команде более 10 Unity-разработчиков, и их навыки сильно различаются: кто-то хорош в архитектуре, а кто-то — в создании прототипов.

Здесь возникает проблема: если клиент приходит с уникальным проектом, предсказать его требования заранее практически невозможно. Найм кандидата занимает, в среднем, месяц, а клиенты хотят начинать работу уже на следующей неделе. Да и нанимать кандидата под конкретный проект, который закончится через 3-6 месяцев не выгодно ни кандидату ни нам.


А теперь важный вопрос:
Какими компетенциями должен обладать Unity-разработчик?

Вот расширенный список навыков, которые пригодятся в работе

(50%) означает, что 50% проектов в нашей компании, а также в проектах, которых я принимал участие требовали наличие этого навыка.
Проценты несут ознакомительный характер и отражают мой опыт. Опыт вашей компании будет отличатся. Вы можете менять или объединять пункты исходя из специфики вашей
* - помечены темы, которые мы спрашиваем на собеседовании

🎯 Знание движка Unity* (100%)
Базовые знания Unity: MonoBehaviour, Корутины, отличие Update от FixedUpdate, NavMesh, Animator, Поиск пути, Опыт написание кастомного редактора,

🎯 Unity 3d* (70%)
Что такое Mesh и из чего состоит 3d модель, Оптимизация 3d игр, скелетная анимация

🎯 Unity 2d* (30%)
Понимание Sprite и Sprite Atlas, Скелетная анимация в 2d, В чем основное отличие Unity 2d проектов от Unity 3d

🎯 Physics* (20%)
Теоретическое знание кинематики

🎯 Unity UI* (80%)
Canvas, Layout group, как верстать адаптивный интерфейс, Safe Area
Оптимизация и производительность

🎯 Шейдеры и графика* (5%)
Какие есть пространства в Unity, Shaderlab, Shader graph, Renderer Pipelines, Post Processing, Draw calls

🎯 Оптимизация и профайлинг* (70%)
Big O notation, Profiler, Deep profiling, Frame debugger, Memory profiling, Profiling on device

🎯 Архитектура* (100%)
Паттерны, SOLID, Реактивное программирование, MV* шаблоны, организация данных

🎯 C#* (100%)
Тут много всего. Некоторые темы: ООП, абстрактный класс и интерфейс, атрибуты, Reflection, GC

🎯 Assets* (90%)
Zenject, VContainer, UniRx, Odin, UniTask, Addressables

🎯 Разработка под PC (5%)
Управление джойстиком, Особенности реализации под конкретную платформу (Steam, Epic games)

🎯 Разработка под мобильные платформы* (85%)
Реклама, Аналитика, Конфиги, БД, Пуш уведомления

🎯 Разработка под Web (10%)
Ограничение под WebGL, особенности реализации под конкретную платформу (Yandex игры, Telegram и т. п.)

🎯 AR/VR (0%)
Особенности управление в VR. Asset VRTK, платформа Oculus

🎯 Сетевая разработка* (50%)
Rest API, Сокеты, Мультиплеерные игры, Photon, SaaS

🎯 ECS (0%)
Понимание ECS архитектуры, LeoECS, Morpeh, Entitas, DOTS, другие реализации

Разработка под PC, AR/VR, Web имеют маленький процент, так как большинство наших заказов это мобильные игры
Архитектура имеет 100%, так как она нужна везде, но для прототипов не критична. Кандидат с хорошим знанием архитектуры просто сделает прототип качественнее
ECS имеет 0% так как у нас нет проектов с таким архитектурным подходом

💡 Буду очень признателен, если вы заполните форму (1 мин) о навыках на вашем проекте

🎯 Матрица компетенций: инструмент для распределения задач

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

🛠 Зачем она нужна?
Представьте, что в вашей команде 5 Unity-разработчиков, и вы распределяете задачи на новый спринт. Можно:
1️⃣ Спросить, кто что хочет взять.
2️⃣ Довериться своему опыту.
3️⃣ Или воспользоваться матрицей компетенций — удобной "шпаргалкой", которая наглядно покажет сильные и слабые стороны каждого разработчика.

А если у вас 10 разработчиков? Удержать всю информацию в голове становится практически невозможно.

🔍 Пример матрицы компетенций

Вася Пупкин
* Unity3D: 4
* Physics: 5
* Multiplayer: 0
* Система скилов: 4
* Скорость работы: 5
* Коммуникации: 5

Фича: Скилл заморозка
* Unity3D: 5
* Physics: 0
* Multiplayer: 0
* Система скилов: 5
* Скорость работы: 5
* Коммуникации: 3

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

🎨 Лайфхаки использования
Выделяйте зелёным навыки, которые сотрудник хочет прокачивать, а красным — те, которые не вызывают интереса.
Матрица полезна не только для техлидов, но и для тимлидов или менеджеров проектов.

📈 Когда стоит внедрять матрицу компетенций?
* Команда из 3+ разработчиков.
* Много нетипичных задач или проектов.
* В принятии решений участвует несколько человек.

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

🛠️ Удобный способ работы с коллекциями через Builder

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

Как бы выглядел поиск этого юнита в классической реализации

private Enemy GetEnemyClassic()
{
    var size = Physics2D.OverlapCircleNonAlloc(center.position, radius, results, layerMask);
    
    for (var i = 0; i < size; i++)
    {
        var enemy = results[i].GetComponent<Enemy>();
        
        if (enemy.IsDead)
            continue;
        
        if (enemy.EnemyType != EnemyType.Melee)
            continue;

        return enemy;
    }

    return default;
}

⚠️ Минусы:

* Использование коллайдеров для Physics2D.OverlapCircleNonAlloc.
* Необходимость добавлять специальный слой на врагов (и не забывать добавлять его новым врагам).
* Дорогой вызов GetComponent<Enemy>.
* Сложность восприятия метода при чтении кода.


⚙️ Альтернативный вариант: коллекция + Builder

Я часто использую подход через коллекцию и паттерн Builder.

private Enemy GetEnemyViaBuilder() =>
    enemyCollection
        .InRadius(center.position, radius)
        .IsAlive()
        .Melee()
        .FirstOrDefault();

✅ Преимущества:

* Упрощение кода и повышение читаемости.
* Отсутствие необходимости работать с коллайдерами и слоями.
* Избавление от вызова GetComponent.

⚠️ Минусы:

* Увеличение времени разработки: требуется написать систему фильтрации и поддерживать коллекцию в актуальном состоянии.

✍️ Пример реализации коллекции

public class EnemyCollection
{
    private readonly FilterData filter = new();
    private IEnumerable<Enemy> enemies;

    public EnemyCollection(IEnumerable<Enemy> enemies)
    {
        this.enemies = enemies;
    }

    public EnemyCollection IsDead()
    {
        filter.IsDead = true;
        return this;
    }
    
    public EnemyCollection IsAlive()
    {
        filter.IsDead = false;
        return this;
    }
    
    public EnemyCollection Melee()
    {
        filter.EnemyType = EnemyType.Melee;
        return this;
    }
    
    public EnemyCollection InRadius(Vector3 center, float radius)
    {
        filter.InFilterByRadius = true;
        filter.Center = center;
        filter.Radius = radius;
        return this;
    }

    public Enemy FirstOrDefault()
    {
        return Build().FirstOrDefault();
    }

    public IEnumerable<Enemy> Build()
    {
        if (filter.IsDead.HasValue)
        {
            enemies = enemies.Where(e => e.IsDead == filter.IsDead);
        }
        
        if (filter.EnemyType.HasValue)
        {
            enemies = enemies.Where(e => e.EnemyType == filter.EnemyType);
        }
        
        if (filter.InFilterByRadius)
        {
            enemies = enemies.Where(e => Vector3.Distance(filter.Center, e.transform.position);
        }

        filter.Clear();
        return enemies;
        
    }

    private class FilterData
    {
        public bool? IsDead;
        public EnemyType? EnemyType;
        public bool InFilterByRadius;
        public float Radius;
        public Vector3 Center;
        
        public void Clear()
        {
            IsDead = null;
            EnemyType = null;
            InFilterByRadius = false;
            Radius = 0;
            Center = new Vector3();
        }
    }
}

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

Напишите в комментариях ваше мнение о таком решении! 🚀

Мои неудачи

Всегда приятно говорить о достижениях и успехах, но мой 2024 год – это история неудач

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

В результате поставил себе цель – выпустить 10 игр за год
Спойлер: удалось выпустить 5 игр, а еще одна выйдет в 2025 году

Краткая история игр
1️⃣ Drill Master
Я разрабатывал эту игру параллельно с основной работой. Сидел в выходные и в свободное время в будни, но все же довел проект до маркетинговых тестов. Провел маркетинговые тесты – провал. Проект заморожен.

2️⃣ Bouncing Ball
Сделал эту игру за 7 дней, пока был в отпуске. Быстро провел маркетинговые тесты – результат снова отрицательный. Не раздумывая, выкинул проект и пошел дальше.

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

3️⃣ Galaxy Expansion
Это самая крутая игра из всех, что я сделал за год. Но на ее разработку ушло 4 месяца, что оказалось слишком долго и дорого. За это время можно было сделать 4 прототипа и протестировать их.

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

4️⃣ Chase Car Arcade
Первая игра, которую мы сделали быстро и передали на полноценный тест издательству. Результат предсказуем – игра не прошла по метрикам.

💬 К этому моменту я работал почти без выходных уже 8 месяцев. Переутомление, наложившиеся личные проблемы, а также низкая скорость работы программиста заставили меня взять паузу, расстаться с программистом и переосмыслить подход. В результате мой новый проект Draw Cooked так и остался лежать в репозитории.

💬 Я решил замедлить темп, изучить рынок и опыт других студий. Решил нанимать фрилансеров под конкретные задачи – это оказалось лучшим решением и снизило стоимость прототипа в 2-3 раза

5️⃣ Karlson. Parkour Runner
Первая игра, сделанная с командой фрилансеров. У нее были хорошие метрики, но требовалось много доработок для их улучшения. Я принял решение не вкладываться в доработки и двигаться дальше.

Чему я научился за этот год:
1️⃣ Если ты новичок без опыта продаж своих игр, начинать нужно с коротких проектов, чтобы совершать дешевые ошибки.
2️⃣ Делегируйте разработку. Если проект делаете сами, обязательно делайте паузы и смотрите на него с позиции продюсера.
3️⃣ Изучайте информацию и опыт других. Чем больше учитесь на чужих ошибках, тем выше шансы их избежать.

Поставьте ♥️, если интересно услышать про каждый проект подробнее!

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

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

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

С новым годом! 🎄🎉🎁

Проект Chase Car Arcade 🚗

После провала Galaxy Expansion я решил попробовать другой подход — сделать игру с объемом контента только на маркетинговый креатив. Главная цель такого проекта — отснять маркетинговый креатив и проверить стоимость привлечения пользователя (CPI). На разработку игры ушло всего 2 недели.

📊 Метрики
1️⃣ CPI: >3$
2️⃣ D1: 2%

Ссылочка на Google Play

Результаты оказались неудовлетворительными, и мы решили не продолжать развитие проекта. Вместо этого я перешёл к следующей идее.

Плюсы такого подхода ✅
1️⃣ Возможность быстро проверять идеи и гипотезы.

Минусы такого подхода ❌
1️⃣ Плохой ретеншн в подобных проектах.
2️⃣ Метрики сильно зависят от качества маркетингового креатива.

Уроки из проекта Chase Car Arcade 💡
Этот подход хорош для проверки трендов или экспериментальных механик, но он имеет свои ограничения. Например, без тестирования ретеншна трудно понять долгосрочный потенциал игры.

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

Рекомендации для Hypercasual игр
Многие продюсеры советуют:
🎯 Разрабатывать игру с минимальным, но полноценным контентом, например, 10 уровнями или 10-20 минутами геймплея.

Когда я начинал Chase Car Arcade, я знал это правило, но не понимал его на практике. Этот проект помог мне (и, надеюсь, вам) увидеть, почему важно следовать такому подходу.

Сравнение подходов
* Galaxy Expansion показал недостатки долгой разработки и большого количетва контента
* Chase Car Arcade продемонстрировал минусы минималистичного подхода.

А как вы проверяете свои идеи? Делали ли вы похожие эксперименты? 😅

На днях наткнулся на прекрасный пост про "Сочность" в играх

Оригинал тут

На мой взгляд обязательные знания для всех, кто работает в геймдев индустрии, особенно тем, кто делает прототипы
Всем советую посмотреть гифку из поста!

Это, кстати, то, что мы в первую очередь тестируем у кандидатов во время Live coding на прототипы. Потому что, часто, именно программист отвечает за "сочность"

Коротко смысл в том, что что-бы сделать игру более сочной нужно добавить для действий такие реакции
* Изменение цвета объекта
* Изменение пропорций или другая Tween анимация
* Добавление VFX
* Дрожание камеры
* Звуковой эффект
* Другие эффекты, напрмер замедление времени

Всем привет!
На хабре вышла моя новая статья про процесс автоматизации CI/CD в Unity

Автоматизируй всё! Настройка CI-CD в Unity для ленивых (и умных) разработчиков. Часть первая

3 приёма, которые мгновенно сделают ваш код чище! 🚀

На этой неделе провел серию код ревью и решил сформировать 3 простых, но мощных совета, чтобы ваш код был читаемым и поддерживаемым!

✅ 1. Разбивайте сложные лямбда-выражения
Лямбда-методы удобны, но слишком сложные выражения ухудшают читаемость.

🔴 Плохо:

var evenNumbers = numbers
    .Where(n => n % 2 == 0)
    .Select(n => n * n)
    .OrderByDescending(n => n)
    .ToArray();

🟢 Хорошо (разбиваем на методы):

private bool IsEven(int number) => number % 2 == 0;
private int Square(int number) => number * number;

var evenNumbers = numbers
    .Where(IsEven)
    .Select(Square)
    .OrderByDescending(n => n)
    .ToArray();

Теперь код понятнее и легче отлаживать.

---

✅ 2. Используйте ранний return вместо вложенных if-else
Чем меньше вложенность, тем чище код.

🔴 Плохо:

public void Attack(int damage)
{
    if (damage > 0)
    {
        health -= damage;
        if (health <= 0)
        {
            Die();
        }
        else
        {
            Debug.Log("Player took damage");
        }
    }
    else
    {
        Debug.Log("Invalid damage value");
    }
}

🟢 Хорошо:

public void Attack(int damage)
{
    if (damage <= 0)
    {
        Debug.Log("Invalid damage value");
        return;
    }

    health -= damage;
    if (health <= 0)
    {
        Die();
        return;
    }

    Debug.Log("Player took damage");
}

Ранний return делает код проще и понятнее.

---

✅ 3. Избегайте глубокой вложенности логики
Чем меньше if в if, тем лучше.

🔴 Плохо:

public void ProcessEnemies(List<Enemy> enemies)
{
    foreach (var enemy in enemies)
    {
        if (enemy.IsAlive)
        {
            if (enemy.DistanceToPlayer < 10)
            {
                if (enemy.HasWeapon)
                {
                    enemy.Attack();
                }
            }
        }
    }
}

🟢 Хорошо (разбиваем на методы):

public void ProcessEnemies(List<Enemy> enemies)
{
    foreach (var enemy in enemies)
    {
        HandleEnemy(enemy);
    }
}

private void HandleEnemy(Enemy enemy)
{
    if (!enemy.IsAlive)
        return;
    
    if (enemy.DistanceToPlayer >= 10)
        return;
    
    if (!enemy.HasWeapon)
        return;
    
    enemy.Attack();
}

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

---

💡 Вывод:
✅ Разбивайте сложные выражения на методы
✅ Используйте ранний return, чтобы избежать лишних if-else
✅ Минимизируйте вложенность для лучшей читаемости

Используете ли вы эти методы на практике или они для вас вновинку?
Поделитесь в комментариях👇

🍊"Сочность ревью"

Всем привет! 👋

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

💡 И тут родилась идея — "Сочность ревью".
Суть простая: нужен программист, который сможет на лету настраивать "сочность" игры, используя готовые ассеты. 🎨✨

🛠️ Идея тестового задания:
Хотим проверить навык через лайвкодинг — чтобы кандидат показал, как он видит и делает эффект по-настоящему вкусным.

Пример задания:

На сцене — пол из кубов (100x100) и круг, который прыгает по этим кубам.
Нужно сделать эффект на кубах и круге при приземлении — чтобы выглядело сочно! 🍑💥
🔥 Вопрос к вам:

Как вам такое тестовое? Подходит для проверки скиллов?
И... может, кто-то хочет попробовать себя в этом задании just for fun? 😉

Ставьте 🍓 если идея огонь и 💩 если идея не очень
А если хотите попробовть, то пишите в комменты или в личку!

💡 Немного мыслей с текущего Game Jam'а

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

🎮 1. Игровые движки
Примерно 40% проектов делают на Unreal Engine 5 и около 30% — на Unity (субъективно, джем ещё идёт). Часто вижу проекты на Godot, а также на менее популярных движках вроде Phaser.

🐍 2. Godot
Удивило, сколько новичков выбирают Godot. Кажется, даже больше, чем Unity и Unreal вместе. У движка явно светлое будущее — ждём волну новых инди-игр на нём.

👥 3. Роли участников
Очень много ребят в сфере UI/UX и 2D арта, да и саунд-дизайнеров хватает. А вот разработчиков явно не хватает — многие команды страдают от нехватки кодеров.

🤖 4. Все используют AI
Художники и саунд-дизайнеры активно юзают ChatGPT для генерации простых скриптов. Этого хватает для базовых механик в хоррорах или простых third-person играх.

💬 А что вы думаете по этому поводу? Повлиет ли такое соотношение на игровую индустрию в ближайшее 3-5 лет?

🔧 Как я упрощаю рефакторинг

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

🎯 Совет 1. 1 коммит — 1 правка
🔹 Внесли изменения
🔹 Проверили, что ничего не сломалось
🔹 Закоммитили

🎯 Совет 2. Атомарные изменения
Каждый коммит должен содержать 1 логически завершённое изменение.
Пример:
Вынесли код в отдельный метод — уже повод для коммита.
Допускаю объединение нескольких стилистических изменений в один коммит, но логические изменения лучше разделять.

🎯 Совет 3. Чётко ставьте цель коммита
Пример:
🔹 Коммит 1: Вынести обработку ошибок в отдельный класс.
🔹 Коммит 2: Разделить обработку ошибок на классы с общим интерфейсом.

🎯 Совет 4. Автотесты — если возможно
Покрытие рефакторинга тестами сильно упрощает жизнь.
⚠️ У меня редко получается писать тесты до начала рефакторинга, но если код позволяет — очень советую.

✅ Плюсы подхода:
🔹 Фокусируетесь на каждом этапе, а не рефакторите всё подряд.
🔹 Можно в любой момент прервать работу, завершив текущий коммит.
🔹 Держите в голове меньше контекста.
🔹 Легче понять, где что сломалось, так как каждая правка — отдельная итерация.

🔥 5 советов, как писать код быстрее

Хотите ускорить свою работу в коде? Вот 5 приёмов, которые помогают мне писать быстрее и эффективнее.


🚀 Совет 1. Используйте HotKeys в Rider или Visual Studio

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

Я предпочитаю Rider — он удобнее, на мой взгляд. Но знаю ребят, которые любят Visual Studio. Главное — выучить основные HotKeys и активно использовать их в работе.

Полезные комбинации в Rider:
🔹 Ctrl + Shift + R — рефакторинг кода
🔹 Alt + Enter — быстрые исправления
🔹 Shift + Shift — глобальный поиск

В Visual Studio тоже есть мощные комбинации, например:
🔹 Ctrl + D — дублирование строки
🔹 Ctrl + K, Ctrl + D — автоформатирование кода

Советую посмотреть обучающие видео на Youtube и потратить несколько дней на их изучение


🤖 Совет 2. AI-ассистент — must-have

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

Как помогает Copilot:
🔹Генерирует повторяющиеся конструкции (геттеры, сеттеры, циклы и т. д.)
🔹Подсказывает возможные решения, основываясь на контексте кода

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


📌 Совет 3. "Live Templates" — код за секунды

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

Примеры:
🔹 prop → public int MyProperty { get; set; }
🔹 for → for (int i = 0; i < length; i++) { }
🔹 ctor → создание конструктора класса

В Rider можно создавать свои шаблоны. Например, если вы часто пишете "[field: SerializeField] public type Type { get; private set; }", можно использовть шаблон sprop, который автоматически развернётся в этот код


⌨ Совет 4. Навык слепой печати

Если вы печатаете вслепую, то не тратите время на поиск клавиш, а концентрируетесь на коде. Это значительно ускоряет процесс.

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

Как научиться?
🔹 Сайты типа https://klavogonki.ru помогут натренировать навык.
🔹 Практика каждый день хотя бы 10 минут

У меня скорость печати - 300 символов на Русском и 200 на Английском
👇Пишите в комментариях вашу скорость!


🎛 Совет 5. Программируемая клавиатура

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

Как это помогает?
🔹 Первый слой — стандартное управление, клавиши WASD
🔹 Второй слой — стрелки навигации (без отрыва от основной позиции)
🔹 Третий слой — перемещение по методам в Rider
🔹 Четвёртый слой — управление вкладками, перемещение блоков кода

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

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