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

• Повторение — не всегда плохо
Когда в коде появляются 2-3 одинаковые строки, не спешите их абстрагировать. Часто абстракции ради экономии пары строк только делают код сложнее для восприятия. Правило простое: «Не абстрагируй раньше времени, абстрагируй умно». Если повторение не вызывает затруднений, оставьте его.

• Используй возможности JavaScript
Есть ситуации, когда можно заменить несколько строк на одну — и при этом не потерять читаемости. Не бойтесь использовать тернарные операторы, если они действительно упрощают понимание логики. Главное — одна мысль в одну строку.

// Вместо:
if (isAdmin) return 'admin'
else return 'user'

// Можно:
return isAdmin ? 'admin' : 'user'

• Компоненты должны быть короткими
Если React-компонент начинает занимать больше 50 строк, подумайте, не пора ли его разделить. Логику можно вынести в хук, а часть верстки — в отдельный подкомпонент. Каждый компонент должен выполнять одну задачу, чтобы код оставался читаемым и легко поддерживаемым.

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

function Log(target: any, key: string, denoscriptor: PropertyDenoscriptor) {
const original = denoscriptor.value;
denoscriptor.value = function (...args: any[]) {
console.log(`Call: ${key}(${args.join(', ')})`);
return original.apply(this, args);
};
}

class UserService {
@Log
getUser(id: number) {
return { id, name: 'Alice' };
}
}

new UserService().getUser(42);
// → Call: getUser(42)

— Логирование и аналитика. Декоратор @Log записывает вызовы метода getUser, логируя параметры и результат. Это позволяет мониторить вызовы без изменения их логики. Декораторы, такие как @Log, @Track и @MeasureTime, используются для сбора статистики.

— Валидация и проверка аргументов. С помощью декораторов типа @Validate можно автоматически проверять входные данные. Проверка будет происходить автоматически при вызове метода, без дополнительных шагов.

— DI / инъекция зависимостей. Многие фреймворки, такие как Angular и NestJS, активно используют декораторы для инъекции зависимостей (@Injectable, @Component).

— Access control / Guard’ы. Декораторы также могут применяться для контроля доступа, например, @RequireAuth для проверки авторизации перед доступом к страницам или API.

TypeScript преобразует декораторы в вызовы функций, получающих метаданные элементов. Современный синтаксис декораторов основан на ECMAScript proposal и позволяет использовать несколько декораторов для одного элемента, выполняющихся сверху вниз.

const file = await storageFoundation.open('data.bin');
await file.write(new Uint8Array([1, 2, 3, 4]));
const bytes = await file.read(0, 4);

• Здесь мы открываем файл data.bin, записываем в него данные и читаем их обратно. Это простое и понятное API для работы с бинарными файлами в браузере.

• Storage Foundation API предоставляет мгновенный доступ к данным в пределах sandbox-браузера, поддерживает хранение больших объёмов информации и обеспечивает работу в оффлайн-режиме для PWA.

• Полезно в PWA-приложениях для оффлайн-режима, клиентских базах данных для мини-SQLite, машинном обучении в браузере для хранения моделей и обработки данных, а также в медиа-приложениях для обработки аудио и видео без отправки данных на сервер.

• Storage Foundation API пока экспериментален и доступен только в Chromium-браузерах. Обсуждается его включение в стандарт Web Platform, что ускорит принятие и поддержку в других браузерах.

— Main thread timeline: отслеживай, что именно делает JS и как браузер обрабатывает рендеринг — какие скрипты выполняются, когда происходит layout и paint.
— FPS и CPU usage: сразу видно, где падает производительность, и как нагрузка распределяется по процессору.
— Recalculate Style / Layout / Repaint: цепочка событий, которая показывает, когда браузер реально пересчитывает стили и перерисовывает DOM.
— Flame chart: один из самых эффективных способов понять, какие функции или компоненты (например, в React) занимают много времени на рендеринг.

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

• Включи опции Screenshots и Memory. Это сразу покажет визуальные лаги и поможет отследить утечки памяти.

• Если ты часто видишь события Recalculate Style и Layout — это может быть сигналом, что где-то в CSS происходит ненужное перерасчитывание, например, при использовании offsetWidth внутри цикла.

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

• Performance Insights (beta) — Chrome сам подскажет тебе, какие части кода замедляют работу приложения.
• Web Vitals overlay — на лету покажет LCP, CLS и FID во время профилирования, чтобы увидеть влияние на производительность.
• Performance.mark() и measure() — возможность добавлять свои точки измерения в код

➡️ Отбрасывание лишнего — ключ к простоте
Научиться делать код простым — значит уметь отбрасывать всё лишнее. Это не про то, чтобы уменьшить количество строк до минимума. Нужно не писать «на будущее».

➡️ Понимание задачи — вот что важно
Очень важно понять суть задачи. Чтобы не строить архитектуру для фичи, которая никогда не выйдет в прод.

➡️ Объяснить сложное простыми словами
Важно уметь объяснять сложные вещи не только в коде, но и в PR и документации.

✅ Двумерное выравнивание

Flex работает с одной осью (строка или колонка), но не всегда выравнивает элементы по вертикали и горизонтали. Для этого используется Grid. Пример: карточки товаров с разной высотой описания. Flex создает «рваные» ряды, а Grid выравнивает их идеально по сетке, независимо от высоты контента.

.products {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
gap: 16px;
}

✅ Когда важна структура, а не порядок в HTML

Grid позволяет менять расположение элементов без изменения разметки. В отличие от Flex, который зависит от порядка элементов в HTML, Grid работает по правилам сетки. Используйте grid-area для назначения областей и их изменения местами, включая адаптивные макеты, без JS.

grid-template-areas:
"header header"
"sidebar main"
"footer footer";

✅ Точное позиционирование

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

.item {
grid-column: 2 / 4;
grid-row: 1 / 3;
}

✅ Адаптивность без медиазапросов

Grid автоматически подстраивается под доступное пространство без сложных медиазапросов. Это удобно для адаптации элементов по ширине экрана.

grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));

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

@layer reset, base, components, overrides;

@layer reset {
* { margin: 0; padding: 0; }
}

@layer components {
button { background: var(--accent); }
}

@layer overrides {
.danger button { background: red; }
}

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

• Простое масштабирование больших проектов. Когда проект растёт, важно, чтобы управление стилями было предсказуемым. С @layer это становится возможным.

• Отлично работает с CSS Modules и Design Tokens, что делает это решение ещё более мощным при работе с крупными кодовыми базами и современными методологиями.

• Более безопасная модель доступа: В версии 2.0 добавлена поддержка доступа к файлам через приватные файловые системы с origin-сигнатурой, что значительно улучшает безопасность.

• Поддержка директорий: В новой версии можно работать не только с отдельными файлами, но и с целыми каталогами, что открывает новые горизонты для разработчиков.

• Асинхронные операции: Все операции с файлами теперь выполняются асинхронно, с использованием промисов, что избавляет от блокировок и делает работу с файлами ещё более эффективной.

• Совместимость с Service Workers: Эта совместимость делает File System API идеальным инструментом для создания оффлайн-приложений.

— Текстовые или кодовые редакторы в браузере: Создавайте полноценные редакторы прямо в веб-приложении, с возможностью работы с файлами.

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

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

— Корпоративные дашборды: Экспорт и импорт данных теперь можно делать прямо с локального устройства.

— API всё ещё не поддерживается во всех браузерах.

— Для работы с файлами требуется user consent. То есть пользователи должны явно согласиться на доступ к их файлам.

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

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

❌ Плюсы и минусы:

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

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

• Лёгкость в поддержке кодстайла и линтеров
Можно настроить единый кодстайл и линтеры для всего репозитория, что помогает поддерживать чистоту кода.

• Простота навигации и кросс-рефакторинга
Все пакеты и модули в одном месте — проще искать и изменять код, особенно когда нужно сделать кросс-рефакторинг.

• CI/CD может замедляться без грамотного кеширования
Когда проект становится слишком большим, процессы CI/CD могут стать медленными, если не настроить их правильно.

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

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

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

❌

Плюсы и минусы:

• Простота изоляция и независимые релизы и CI/CD

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

• Легче мигрировать и экспериментировать

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

• Повторение конфигураций и версионный ад

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

• Сложности с централизованными обновлениями

Когда нужно обновить общие утилиты или библиотеки, это становится сложным и трудоёмким процессом.

// Проверяем поддержку
if ('showSaveFilePicker' in window) {
const handle = await window.showSaveFilePicker({
suggestedName: 'data.txt',
types: [
{
denoscription: 'Text file',
accept: { 'text/plain': ['.txt'] },
},
],
});

const writable = await handle.createWritable();
await writable.write('Hello, world!');
await writable.close();

console.log('Файл сохранён прямо на диск');
} else {
console.log('File System API не поддерживается в этом браузере');
}

• showSaveFilePicker() — открывает системный диалог для сохранения файла
• createWritable() — создаёт поток записи в файл
• write() — записывает данные в файл
• close() — закрывает поток и сохраняет файл на диск

ITCSS (Inverted Triangle CSS) — структурированный подход с разделением стилей на слои: общие наверху, специфичные внизу. Обеспечивает порядок, предсказуемость и гибкость, но может быть громоздким для небольших проектов.

• Settings — переменные, которые задают глобальные параметры
• Tools — функции и миксины, которые помогают управлять стилями
• Generic — базовые стили, например, normalize или reset
• Elements — стили для HTML-элементов
• Objects — макетные паттерны, такие как сетки или карточки
• Components — конкретные элементы интерфейса, например, кнопки или карточки
• Utilities — точечные стили для специфичных случаев, например, margin-top или z-index

CUBE CSS — современный подход Энди Белла, фокусирующийся на принципах организации, а не структуре папок. Основная идея: Keep CSS modular and predictable. Подходит для Tailwind, CSS Modules и CSS-in-JS.

• Composition — компоненты и layout-паттерны, например, flexbox или grid
• Utility — маленькие одноцелевые классы, например, .flex или .gap
• Block — самодостаточные компоненты, например, .card
• Exception — редкие и специфичные оверрайды для нестандартных случаев

BEM 2.0 остаётся популярным методом для описания структуры стилей, оставаясь гибким и совместимым с ITCSS или CUBE CSS. Основная идея — чистота и предсказуемость. Это отличный инструмент для модульности и масштабируемости. Теперь вместо громоздких классов типа .btn__icon__wrapper__span используется осознанное написание стилей.

• .block — основной компонент
• .block__element — элемент внутри блока
• .block--modifier — модификатор блока

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

/src/styles/
├─ settings/
├─ tools/
├─ generic/
├─ elements/
├─ objects/
├─ components/
└─ utilities/

• Легче предсказать каскад, стили не «воюют» между собой
• Удобно для масштабных проектов с десятками разработчиков
• Отлично комбинируется с BEM для организации структуры классов

<button class="btn btn--primary">
<span class="btn__icon"></span>
<span class="btn__text">Save</span>
</button>

.btn { padding: .5rem 1rem; border-radius: 4px; }
.btn--primary { background: blue; color: white; }
.btn__icon { margin-right: .5rem; }

• Простой и понятный DOM, который легко навигировать
• Лёгкость в рефакторинге компонентов
• Минимизация конфликтов стилей благодаря чёткой структуре
• Используй BEM вместе с другими архитектурными подходами, такими как ITCSS или CUBE
• Избегай глубоких цепочек классов, например .card__header__noscript — это уже лишнее
• Применяй BEM с токенами и дизайн-системами для лучшей совместимости
• Держи имена классов короткими и логичными