✅ Метод «Википедии»
Не можете найти общий язык с коллегами? Заведите раздел в корпоративной вики, где будете подробно описывать все «косяки» ваших товарищей. Скриншоты, временные метки и даже свидетели – всё в помощь! Через год у вас будет целая энциклопедия непроверенных данных, а новые сотрудники точно оценят вашу внимательность. Главное — не забывайте развивать «историю».

✅ Техника «Zoom-бомбинга»
Следующий уровень: не бояться вмешиваться в чужие встречи. Особенно когда это ретроспективы других команд. Ну, а если коллега с начальником один на один? Скажите, что у вас «появился важный вопрос», и добавьтесь в Zoom-сессию. Так вы точно «услышите» не только своё мнение.

✅ Стратегия «Героического непонимания»
Получил задачу, которую сразу не понял? Не спеши спрашивать. Поищи ошибки в коде, перепиши часть проекта и создай несколько гипотез. И только когда дедлайн уже на носу, напиши в чат: «Кто-нибудь понимает, о чём речь?» Ты же герой, и время для вопросов настало лишь накануне релиза.

✅ Метод «Git-археологии»
Каждая ошибка коллеги должна стать поводом для расследования. И неважно, что это было два года назад. «А вот в коммите от марта ты сделал то же самое!» Найди старые косяки и просто забудь про свой собственный вклад в проект.

✅ Стратегия «Собеседование саботажа»
Приехали на собеседование? Отлично! Теперь нужно создать атмосферу для будущих разработчиков. Садитесь в телефоне, задавайте вопросы, не относящиеся к теме, и жалуйтесь на отсутствие талантов. Главное — дайте понять, что молодёжь не та.

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

✅ Кросс-браузерность и адаптивность: Интерфейс может выглядеть идеально в Chrome, но ломаться в Safari или на мобильном. С тестами таких проблем можно избежать, проверяя поведение компонентов на разных устройствах и браузерах.

✅ UI/UX баги: Строго говоря, это не «классовые» баги, а проблемы, которые влияют на восприятие приложения. Несоответствие дизайну, неправильные анимации — всё это может уйти незамеченным в процессе обычного тестирования, но сказаться на восприятии вашего продукта.

👀 Cypress: Простой и мощный инструмент для энд-ту-энд тестирования. Он позволяет тестировать, как ваш интерфейс ведет себя в реальных сценариях: клики, заполнение форм, навигация, и многое другое. Cypress особенно удобен для динамичных SPA-приложений, где важно протестировать все возможные переходы и взаимодействия.

👀 Если вам нужно больше гибкости, попробуйте Playwright. Он поддерживает тестирование нескольких браузеров и идеально подходит для тестирования UI на разных платформах, таких как Chrome, Firefox и WebKit. А ещё, в отличие от Cypress, Playwright поддерживает тестирование мобильных устройств из коробки.

👀 React Testing Library: Если вы работаете с React, этот инструмент поможет вам тестировать компоненты с учётом пользовательских взаимодействий. Он фокусируется на тестах, которые проверяют не только логику, но и правильное поведение в контексте UI. Например, как компоненты реагируют на пользовательский ввод или как они отображаются при разных состояниях.

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

// Представьте, что вам нужно отследить, кто и когда обращается к объекту. Вместо того чтобы забивать код десятками console.log, можно просто использовать Proxy для перехвата. Теперь любое обращение к объекту будет логироваться. Это очень удобно, если вы работаете с большими стейтами, как в Vue или MobX.

const user = { name: "Alex", age: 25 };

const loggedUser = new Proxy(user, {
get(target, prop) {
console.log(`GET ${prop}`);
return Reflect.get(target, prop);
},
set(target, prop, value) {
console.log(`SET ${prop} = ${value}`);
return Reflect.set(target, prop, value);
}
});

loggedUser.name; // GET name
loggedUser.age = 26; // SET age = 26

// Proxy может отловить некорректные значения и не дать им попасть в бизнес-логику. С таким подходом можно сделать простые data-models без классов и лишнего кода. Валидация и контроль за данными — проще не бывает.

const product = new Proxy({}, {
set(target, prop, value) {
if (prop === 'price' && value < 0) {
throw new Error("Цена не может быть отрицательной");
}
return Reflect.set(target, prop, value);
}
});

// Reflect — набор методов для безопасной работы с объектами. Они выполняют стандартные операции, но предотвращают неожиданные ошибки и обеспечивают предсказуемое поведение.

Reflect.get(obj, 'key'); // вместо obj.key
Reflect.set(obj, 'key', 'value'); // возвращает true/false, не выбрасывает ошибки

// Комбо с Proxy выглядит так:
const safe = new Proxy(obj, {
get: (t, p) => Reflect.get(t, p),
set: (t, p, v) => Reflect.set(t, p, v)
});

<!-- В классическом CSS мы описываем сущности. Utility-first CSS — это немного другой подход. Вместо того чтобы описывать компоненты, мы описываем свойства. Каждый класс — это атомарная единица стиля, которая выполняет одно действие. Когда нужно собрать сложный элемент, мы комбинируем несколько таких атомов, чтобы получить нужный результат -->

<button class="bg-black text-white rounded-lg px-4 py-2">Click</button>

• Открыл HTML и сразу видишь, как выглядит элемент. Нет нужды прыгать по CSS-файлам, чтобы понять, как что-то стилизовано.

• Изолированность без сложных каскадов. Нет таких длинных цепочек, как .card .button.active:hover. Всё работает локально и предсказуемо.

• Нужно создать новый элемент? Просто комбинируешь существующие утилиты, без копирования и написания новых классов. Не нужно писать «ещё одну кнопку, только поменьше».

• Если нужно изменить отступы, это быстрее, чем искать, где в CSS заданы padding. Например, меняем класс px-4 на px-6 и сразу видим результат.

Этот подход можно применить и без фреймворка.

— Заведи слой утилит в обычном CSS:

.flex { display: flex; }
.gap-2 { gap: 0.5rem; }
.text-sm { font-size: 14px; }

— Используй CSS custom properties для хранения токенов, как --color-primary, --space-sm.
— Используй PostCSS или UnoCSS, чтобы собирать утилиты динамически.

Если команда не договорится об atomic naming и начнёт использовать названия вроде text-12px flex1 mt-8px, это может привести к путанице и усложнить понимание кода. Особенно это критично в проектах без дизайн-системы, где утилиты могут превратиться в хаос. В таких ситуациях лучше использовать гибридный подход, комбинируя утилитарный стиль с обычными компонентами, чтобы обеспечить масштабируемость и переиспользование блоков.

Вы наверняка знаете, что :not() используется для исключения элементов с определенным классом или позицией в списке. Например, стиль применяется ко всем элементам .link, кроме последних в списке. Однако :not() позволяет комбинировать несколько условий. Код применяет стиль ко всем img без атрибута class и не являющихся первыми детьми в родительском элементе. Это возможно благодаря тому, что :not() принимает несколько селекторов, разделённых запятыми.

/* Базовое применение */
.link:not(:last-child) {
margin-left: 1rem;
}

/* Применение для всех img, кроме тех, у которых есть атрибут class */
img:not([class], :first-child) {
margin-block-start: var(--ds-typography-img-margin-block-start, var(--_ds-typography-main-margin));
}

Что если вы хотите применить стиль только к тем элементам, которые не содержат в себе определённого соседа? Это легко сделать, используя комбинацию :not() и :has(). В примере стиль background-color: lightblue применяется ко всем параграфам <p>, за которыми не следует элемент <h2>. Это позволяет точно контролировать, какие элементы подвергать стилизации, не добавляя лишних классов или элементов разметки.

<body>
<h1>Париж</h1>
<p>Столица и крупнейший город Франции...</p>
<h2>История</h2>
<p>Париж вырос на месте поселения...</p>
<p>Поселение располагалось на безопасном острове...</p>
</body>

/* Применяем стиль только к параграфам, за которыми не следует элемент h2 */
p:not(:has(+ h2)) {
background-color: lightblue;
}

Псевдо-класс :not() — это просто огонь-фича для тех, кто любит делать код проще и понятнее. Он позволяет исключать элементы по разным условиям, что значительно упрощает создание сложных селекторов. В отличие от старых методов, :not() даёт вам больше свободы и точности.

С его помощью можно создавать более чистые и понятные разметки, которые легко подстраиваются под изменения в структуре документа. Это как улучшенная версия селекторов :first-child или :last-child, только с гораздо большими возможностями.

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

✅ Кросс-браузерность и адаптивность: Интерфейс может выглядеть идеально в Chrome, но ломаться в Safari или на мобильном. С тестами таких проблем можно избежать, проверяя поведение компонентов на разных устройствах и браузерах.

✅ UI/UX баги: Строго говоря, это не «классовые» баги, а проблемы, которые влияют на восприятие приложения. Несоответствие дизайну, неправильные анимации — всё это может уйти незамеченным в процессе обычного тестирования, но сказаться на восприятии вашего продукта.

👀 Cypress: Простой и мощный инструмент для энд-ту-энд тестирования. Он позволяет тестировать, как ваш интерфейс ведет себя в реальных сценариях: клики, заполнение форм, навигация, и многое другое. Cypress особенно удобен для динамичных SPA-приложений, где важно протестировать все возможные переходы и взаимодействия.

👀 Если вам нужно больше гибкости, попробуйте Playwright. Он поддерживает тестирование нескольких браузеров и идеально подходит для тестирования UI на разных платформах, таких как Chrome, Firefox и WebKit. А ещё, в отличие от Cypress, Playwright поддерживает тестирование мобильных устройств из коробки.

👀 React Testing Library: Если вы работаете с React, этот инструмент поможет вам тестировать компоненты с учётом пользовательских взаимодействий. Он фокусируется на тестах, которые проверяют не только логику, но и правильное поведение в контексте UI. Например, как компоненты реагируют на пользовательский ввод или как они отображаются при разных состояниях.

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

Анимация свойств, таких как width, height, margin, padding, top и left, требует от браузера выполнения нескольких ресурсоёмких шагов: Reflow (пересчёт размеров и расположения элементов), Repaint (перерисовка частей страницы) и отображение на экране. Эти процессы могут значительно замедлить работу страницы, особенно при большом количестве элементов, что негативно сказывается на её производительности.

Для повышения производительности веб-анимаций рекомендуется использовать свойства, обрабатываемые графическим процессором (GPU), вместо центрального процессора (CPU). Это позволяет избежать лишних вычислений и ускоряет отображение, особенно при анимации таких свойств, как transform (например, translate, scale, rotate) и opacity (прозрачность). В этих случаях браузеру не нужно пересчитывать размеры элементов или перерисовывать всю страницу, так как изменения происходят на уровне графики, что значительно улучшает производительность.

/* Когда вы анимируете left, браузер выполняет перерасчёт и перерисовку страницы. Этот способ медленный, так как каждый сдвиг элемента требует выполнения операций reflow и repaint. */

.element {
transition: left 0.5s ease;
}

/* При использовании transform, браузер просто сдвигает элемент на графическом уровне, избегая дополнительных перерасчётов. Здесь браузер применяет изменения только на уровне GPU, что делает анимацию плавной и быстрой. */

.element {
transition: transform 0.5s ease;
}

<<!-- Первое поле с логином зелёное (корректно заполнено). Второе поле с паролем красное (пусто и недействительно) -->
<body>
<form class="form">
<div class="form__group">
<label for="name">Введите логин</label>
<input id="name" type="text" value="melnik909" required>
</div>
<div class="form__group">
<label for="password">Введите пароль</label>
<input id="password" type="password" required>
</div>
<button>Войти</button>
</form>
</body>

<style>
input:invalid {
box-shadow: 0 0 10px red;
}

input:valid {
box-shadow: 0 0 10px green;
}
</style>

input:user-invalid {
box-shadow: 0 0 10px red;
}

input:user-valid {
box-shadow: 0 0 10px green;
}

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

/* Предположим, вы хотите загрузить данные с API в фоновом режиме. Вместо того чтобы инициировать запрос сразу и блокировать основной поток, можно использовать requestIdleCallback: */
function fetchDataInIdleTime() {
requestIdleCallback(() => {
fetch('/some-api')
.then(response => response.json())
.then(data => {
console.log('Data loaded in idle time:', data);
})
.catch(error => console.error('Error loading data:', error));
});
}

fetchDataInIdleTime();

— Мы создаём функцию fetchDataInIdleTime(), которая запускает requestIdleCallback.

— Внутри колбэка выполняем асинхронный запрос к серверу.

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

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

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

const observer = new IntersectionObserver((entries, observer) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
// Загружаем изображение, когда оно попадает в область видимости
entry.target.src = entry.target.dataset.src;
observer.unobserve(entry.target);
}
});
});

const images = document.querySelectorAll('img.lazy');
images.forEach(img => observer.observe(img));

— Предположим, вы хотите отложить загрузку изображений до тех пор, пока они не окажутся в области видимости.
— Здесь мы создаём новый IntersectionObserver.
— Для каждого изображения с классом .lazy, как только оно появляется в зоне видимости, происходит загрузка изображения.
— Весь этот процесс запускается только в нужный момент, что минимизирует ненужные операции.