Здарово, работяги! 💪

В прошлом посте я начал разговор про System Design, давайте продолжим.

Представим ситуацию. Солнечный денёк, ветер за окном треплет листья деревьев... 🍃☀️ Вы сидите, себе работаете, попиваете кофеёк ☕️... У вас интересные задачки... Вы можете сконцентрироваться на работе... Представили? Тогда идём дальше. Сидите, работаете, никого не трогаете...
И тут вам прилетает сообщение, сообщение от коллеги из саппорта 😈... В письме он говорит, что у них за час/день/другой промежуток времени накопилось большое количество обращений от пользователей, которые жалуются, что не могут использовать какую‑то функциональность вашего приложения. Вы начинаете судорожно вспоминать, когда был последний релиз, и понимаете, что совсем не 5 минут назад... И тут вашу концентрацию, великолепный настрой и всё хорошее просто сметает к чёртям, заменяя холодным потом и кучей тревог 😰, да ещё и кофе перестал быть вкусным, а приобрёл вкус страданий — если ещё не пили такой, то попробуйте, считаю его самым бодрящим.

Знакома ли вам такая ситуация? Мне — да. И, к сожалению, в моей памяти количество таких эпизодов не равно одному... Бррр, как вспомню — аж передёргивает...

Что же делать, чтобы в такой ситуации не оказаться? Писать хороший код, скажете вы. Хорошее решение!) Конечно, нужно стараться, но ошибки действительно случаются, случаются баги и т. д. И в таких ситуациях самое главное — скорость детекта проблемы и скорость восстановления ⏱️.

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

Если вы никогда не сталкивались с таким, то у вас, скорее всего, возникнет вопрос: с чего начать? Что мониторить? ❓
Вариантов большое количество, но совершенно точно я предложил бы начать именно с ошибок. Таким образом вы сможете понять следующее:

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

Также не забывайте, что для разбора важно логировать информацию не только о названии ошибки, но и контекст - версия/релиз, окружение, браузер/ОС, stacktrace и другую подобную информацию, которая позволит вам быстрее разобраться с ошибкой и ускорит время восстановления.

Следующим шагом может стать настройка алёртов(автоматическое оповещение, при возникновении определеныых условий) — они позволят вам узнавать о проблемах быстро и не сидеть, гипнотизируя графики, весь день.🚨 Реакцию на них добавьте в рутину вашего дежурного (On call)

Для организации мониторинга ошибок есть множество решений. Скорее всего вы слышали про Sentry, Raygun, Bugsnag и прочее. Но вы, может быть, уже заметили, что я в последнее время часто пишу про открытые отечественные решения, т. к. у многих из вас могут быть проблемы с использованием зарубежных решений. Тут тоже задался вопросом, а что такого на рынке есть, и нашёл — Хоук. Потыкал его какое‑то время на своих пет‑проектах и могу вам его посоветовать.
Основные фичи(критичные для меня):
- Реалтайм мониторинг ошибок
- Возможность логировать не только название ошибки, но и контекс - stack trace, релиз, коммит, окружение и тд
- Алерты
- Поддержка Source Maps
- Настройка доступов
- Open source SDK(полезно посмотреть как устроен инструмент, котрый вы используете)

Также, как я и говорил выше, ПО отечественное, поэтому:
- Серверы в РФ, а для многих это сейчас критично;
- Можно оплачивать RU‑картой (для меня это супер‑критерий, т. к. я очень не люблю всю бумажную, банковскую волокиту). 💳

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

Здарова, работяги!

Я уже достаточно давно подписан на Никиту и со многими его постами согласен - например с этим.

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

Критическое мышление. Анализируй, сомневайся, формируй свое мнение. Том Чатфилд

Думай как математик: Как решать любые задачи быстрее и эффективнее. Барбара Оакли

Думай медленно… Решай быстро. Даниэль Канеман

Джедайские техники и Путь джедая. Максим Дорофеев

Эссенциализм. Путь к простоте. МакКеон Грег

Программист-прагматик. Путь от подмастерья к мастеру. Томас Дэвид, Хант Эндрю

Атомные привычки. Джеймс Клир

Cohesion и Coupling 🧩🔗

Здарова, работяги!

Если очень коротко: хорошая архитектура — это высокая связность внутри модулей (cohesion) и низкая связанность между ними (coupling). Эти два термина отлично объясняют, почему код либо живёт годами, либо рассыпается от каждого чиха.

В оригинале различить их достаточно просто, но вот в переводе… связанность и связность… Если у вас есть дефекты речи или вы просто устали к концу дня, то готовьтесь к сумбуру. Поэтому я обычно использую другой перевод:
— Cohesion — Связность
— Coupling — Сцепленность

Связность (Cohesion) 🧲
— Насколько сильно и «по делу» связаны части внутри модуля/компонента.
— Высокая связность = модуль делает одну понятную вещь.
— Сигнал проблемы: описываете модуль через «и-и-и» — «карточка товара грузит, форматирует цену, читает локаль и отправляет аналитику».

Сцепленность (Coupling) 🔗
— Насколько сильно модуль зависит от других.
— Низкая сцепленность = модуль знает только минимально необходимое о внешнем мире.
— Сигнал проблемы: изменение структуры store/API ломает полприложения.

Пример 🍿

Плохо: низкая связность + высокая сцепленность

function ProductCard({ id }: { id: string }) {
  const [product, setProduct] = React.useState<any>(null);

  React.useEffect(() => {
    fetch(`/api/products/${id}`)
      .then(r => r.json())
      .then(setProduct);

    window.analytics.track('view_product', { id });
  }, [id]);

  if (!product) return <>Loading...</>;

  const currency = localStorage.getItem('currency') || 'USD';
  const priceText = new Intl.NumberFormat('en', { style: 'currency', currency })
    .format(product.price);

  return (
    <div>
      <img src={product.image} />
      <div>{product.name}</div>
      <div>{priceText}</div>
    </div>
  );
}

— Компонент делает всё: загрузка, форматирование, аналитика, работа со storage, UI.
— Жёсткая привязка к fetch, analytics, localStorage, Intl и структуре product.
— Любое внешнее изменение тянет правки сюда.

Хорошо: высокая связность + низкая сцепленность

type Product = { id: string; name: string; image: string; price: number };
type ProductApi = { getById(id: string): Promise<Product> };
type CurrencyFormatter = (currency: string, amount: number) => string;

function ProductCardView({ product, priceText }: { product: Product; priceText: string }) {
  return (
    <div>
      <img src={product.image} />
      <div>{product.name}</div>
      <div>{priceText}</div>
    </div>
  );
}

type Props = {
  id: string; api: ProductApi; currency: string; formatPrice: CurrencyFormatter;
}

function ProductCard({ id, api, currency, formatPrice }: Props) {
  const product = useProduct(id, api);

  if (!product) return <>Loading...</>;

  const priceText = formatPrice(currency, product.price);

  return <ProductCardView product={product} priceText={priceText} />;
}

— ProductCard оркестрирует UI конкретной карточки (высокая связность).
— Зависимости приходят снаружи: api, formatPrice, currency (низкая сцепленность).
— Легко подменять реализации.

Опасные виды сцепленности на фронте 🛑
— Компонент знает «внутренности» ответа бэкенда и лезет в deeply.nested.a.b.c.
— Временная: функция/эффект B должна вызываться строго после функции/эффекта A (завязка на порядок эффектов).
— Прямое использование window, document, localStorage прямо в компоненте.
— Зависимость от окружения: компонент «знает», что он в проде/тесте.

Как снижать coupling и повышать cohesion 🛠
— Интерфейсы и адаптеры: компоненту нужен api.getById, а не fetch/axios.
— DI через props/context: прокидывайте зависимости сверху.
— Разделяйте UI и данные: View без побочек, отдельные сервисы для данных и бизнес-логики.
— Избегайте «utils.ts на 1000 строк»: маленькие тематические модули (price/strings/date).

...продолжение

Как понять, что связность низкая? 🔍
— Трудно назвать модуль одним коротким предложением.
— Слишком много зависимостей «на всякий случай».
— Тесты громоздкие: чтобы проверить одну вещь — поднимаете полприложения.

Как понять, что сцепленность высокая? ⚠️
— Изменение структуры ответа API ломает десяток компонентов.
— Нельзя протестировать без реального network/localStorage.
— Переезд на другую библиотеку (http, стейт) требует массовых правок.

Мне очень нравится идея Ларри Константина: «Попытка разбиения на части модуля, обладающего связностью, приведёт лишь к увеличению степени связанности кода и снизит его удобочитаемость».

Итого 🧾
— Высокая связность = модуль делает одну вещь и делает её хорошо.
— Низкая сцепленность = модуль знает минимум о внешнем мире и легко заменяет зависимости.

Хорошое решение для снижения coupling - Dependency Injection. Интересно ли вам почитать про DI?

Зачем разработчику комьюнити, если есть книги и YouTube? 🧠🤝

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

Но у этого пути есть предел — актуальность. Для фундаментальных вещей книги — мой топ-1. А вот для новых технологий, библиотек, подходов и каких-то «затычек» в решениях, исследованиях лучший источник оказался другой — общение с людьми. Комьюнити, митапы, конференции, кулуарные разговоры после докладов. Самые яркие инсайты за последний год-два я получал именно там.

Плюсы комьюнити:
— Актуальные практики «как делают сейчас», а не год назад - книги пишутся не один день
— Контекст решений: почему сработало и какие компромиссы приняли - часто в статьях упускают важные для вашего кейса детали
— Быструю обратную связь и проверку гипотез
— Контакты, которые помогают с карьерой и проектами - сейчас всё чаще слышу про этот плюс

Может показаться, что чтобы начать погружаться в сообщество необходимо покупать дорогущий билет на крутую конфу (тоже хороший вариант, там еще и доклады интересные😏), но начать можно с ваших локальных сообществ, митапов, либо с формата, который организуют ребята из mindbox — Frontend Speed Dating.

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

📅 Когда: 7 октября

⏰ Во сколько: 19:00–20:30 по мск

📍 Где: Zoom (ссылку пришлём после регистрации)

Зарегистрироваться

Здарова, работяги!

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

Общий призовой фонд в этом году составит 12 миллионов рублей!

Этапы Yandex Cup 2025:
• 20-29 октября — пробный тур для знакомства с платформой и задачами
• 2 ноября — квалификация, где будут определены 180 финалистов
• 5-7 декабря — финал и церемония награждения в Стамбуле

Призы в направлении Фронтенд:

1 место — 500 000 ₽
2 место — 400 000 ₽
3 место — 300 000 ₽
4 место — 200 000 ₽
5 место — 100 000 ₽

Лучшие участники направления смогут по упрощенной схеме пройти собес в компанию и получить офер

Регистрация открыта до 29 октября: тык👈

<Activity></Activity>

Здарова, работяги!

Наконец-то я добрался до докладов с React Conf 2025.

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

Начнем с компонента Activity.

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

Что это нам даёт?

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

Возможность заранее рендерить кусочек интерфейса — уже более интересный кейс. Если компонент Activity скрыт во время первоначальной отрисовки, его дочерние элементы не будут видны на странице. Но! Самое важное! Они всё равно будут рендериться. У меня было тут два основных опасения: влияние на перф и фоновые эффекты. Но эти моменты продумали: приоритет рендеринга у таких элементов ниже, чем у видимых, а эффекты в них не будут срабатывать.

Сегментация для выборочной гидрации — пожалуй, самое интересное. Selective Hydration позволяет сократить ожидание интерактивности интерфейса — пользователь может быстрее жать на нужные кнопочки. Раньше для разделения дерева на независимые части вы, скорее всего, использовали Suspense, но его использование только для селективной гидрации будет порождать моргания плейсхолдера. Activity лишен этого косяка, но также позволяет выделить независимые части, гидрацию которых можно либо отложить, либо ускорить.

Но! Есть и подводные камни.

Всё, что вы не очистили в cleanup (таймер, интервал, видос, аудио, iframe и т. д., и т. п.) после скрытия может продолжать жить «в фоне» — ждите проблем. Так, например, интервал, обновляющий локальный стейт, продолжит это делать и в скрытом состоянии, а после показа элемента вы увидите последствия его скрытой работы, т. к. стейт при скрытии/показе не сбрасывается.

Может возникнуть вопрос: «А почему не использовать для скрытия css???»

Жизненный цикл и эффекты
- CSS: компонент остаётся смонтирован, эффекты продолжают работать.
- Activity: перед скрытием выполняется cleanup; эффекты «спят», пока поддерево скрыто.

Рендер/перформанс
- CSS: скрытая часть конкурирует за ресурсы как обычно; планировщик React это не учитывает.
- Activity: скрытому поддереву назначается низкий приоритет; можно безопасно пререндерить его в фоне, не мешая видимому UI.

Гидрация/SSR
- CSS: не даёт границы для выборочной гидрации — гидрируется всё как обычно.
- Activity: формирует сегменты для Selective Hydration — можно откладывать/ускорять гидрацию скрытых частей.

Итого: штука интересная, кейсов применения много, посмотрим, как будет использоваться.

#тимлидство

Здарова, работяги!

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

Темы модуля:

1. Модели и подходы к управлению изменениями:
Модель Джона Коттера, ADKAR, Липитт-Кностер - разобрали разные схемы, как запускать и закреплять перемены в команде. ADKAR даже уже попробовал на практике - штука рабочая. Также на TeamLeadConf (отдельный пост напишу) обсуждал эти модели с лидами из других компаний - многие активно применяют, поэтому советую обратить внимание на эти модели, если еще не знакомы.

2. Иммунитет к изменениям:
Почему опытные команды иногда саботируют даже здравые решения, какие глубинные убеждения включают "внутреннего луддита", и как это раскрывать через честные диалоги и спецтехники. Важный инсайд - в каждом из нас живёт свой маленький "хранитель стабильности", важно научиться распознавать, когда он беспокоится по делу, а когда просто - "Раньше было лучше!".

3. Культура открытости и Growth Mindset:
Фиксированное мышление vs Мышление роста - почему мышление роста - это не модный термин, а прямой драйвер для внедрения инноваций. Про осознанность, честный фидбек, безопасную среду, где можно ошибаться, учиться и цепляться за новые возможности.

4. Стратегические и тактические изменения:
Осваивали подходы от малых изменений (incremental), которые делают развитие постоянным процессом, до "больших шагов" и трансформирующих поворотов - когда нужно не просто подкрутить процессы, а серьезно заняться "краксом" (узловой проблемой) (об этом много написано у Ричарда Румельта).

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

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

В сухом остатке:
- ADKAR и Коттер действительно рабочие вещи, а не просто сказки седого старца - поэтому обязательно изучаем.
- Ритуалы, артефакты, честная коммуникация, быстрая обратная связь и маленькие победы - must have для любой трансформации.
- И не будьте луддитом, старайтесь быть открытым новому, но не забывайте про критическое мышление - тут важен баланс. Особенно это актуально в текущее время, чтобы балансировать между фанатиками и старообрядцами и внедрять действительно полезные улучшения в области ai.

А теперь вопрос вам: какие перемены реально запускали у себя, где было самое сильное сопротивление, и что реально помогло? Делитесь инсайтами, рецептами и фейлами 👇

ELIMINATING WATERFALLS

🔴 CRITICAL Impact (2–10× улучшение)

Promise.all() для независимых операций
Самое базовое и важное правило — параллелизация независимых операций

❌ Неправильно (3 round trips):

const user = await fetchUser()
const posts = await fetchPosts()
const comments = await fetchComments()

✅ Правильно (1 round trip):

const [user, posts, comments] = await Promise.all([
  fetchUser(),
  fetchPosts(),
  fetchComments()
])

Мои мысли: Логичное уменьшение критического пути за счёт параллельного старта всего, что не зависит друг от друга. Важно помнить: правило применимо только к независимым запросам. Если при падении одного запроса вы всё равно можете продолжать работу — используйте Promise.allSettled().

---

Не допускайте waterfall-цепочек в API routes
Критично для серверного кода — запускайте независимые операции сразу

❌ Неправильно (config ждёт auth, data ждёт обоих):

export async function GET(request: Request) {
  const session = await auth()
  const config = await fetchConfig()
  const data = await fetchData(session.user.id)
  return Response.json({ data, config })
}

✅ Правильно (auth и config стартуют одновременно):

export async function GET(request: Request) {
  const sessionPromise = auth()
  const configPromise = fetchConfig()
  const session = await sessionPromise
  const [config, data] = await Promise.all([
    configPromise,
    fetchData(session.user.id)
  ])
  return Response.json({ data, config })
}

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

---

Dependency-based parallelization
Продвинутая параллелизация — максимизация параллелизма при частичных зависимостях

❌ Неправильно (profile ждёт config без причины):

const [user, config] = await Promise.all([
  fetchUser(),
  fetchConfig()
])
const profile = await fetchProfile(user.id)

✅ Правильно с better-all (config и profile параллельно):

import { all } from 'better-all'

const { user, config, profile } = await all({
  async user() { return fetchUser() },
  async config() { return fetchConfig() },
  async profile() {
    return fetchProfile((await this.$.user).id)
  }
})

✅ Альтернатива без библиотеки:

const userPromise = fetchUser()
const profilePromise = userPromise.then(user => fetchProfile(user.id))

const [user, config, profile] = await Promise.all([
  userPromise,
  fetchConfig(),
  profilePromise
])

Мои мысли: Мне ближе вариант без библиотеки — минимум магии и максимум профита. Библиотека может повышать «выразительность», но, как по мне, читаемость часто становится хуже.

🟡 HIGH Impact

Defer await until needed
Условная оптимизация — await только там, где данные реально используются

❌ Неправильно (всегда загружает permissions):

async function updateResource(resourceId: string, userId: string) {
  const permissions = await fetchPermissions(userId)
  const resource = await getResource(resourceId)

  if (!resource) {
    return { error: 'Not found' }
  }

  if (!permissions.canEdit) {
    return { error: 'Forbidden' }
  }

  return await updateResourceData(resource, permissions)
}

✅ Правильно (permissions грузим только если ресурс найден):

async function updateResource(resourceId: string, userId: string) {
  const resource = await getResource(resourceId)

  if (!resource) {
    return { error: 'Not found' }
  }

  const permissions = await fetchPermissions(userId)

  if (!permissions.canEdit) {
    return { error: 'Forbidden' }
  }

  return await updateResourceData(resource, permissions)
}

Простой пример с early return:

// ❌ Неправильно
async function handleRequest(userId: string, skipProcessing: boolean) {
  const userData = await fetchUserData(userId)

  if (skipProcessing) {
    return { skipped: true }
  }

  return processUserData(userData)
}

// ✅ Правильно
async function handleRequest(userId: string, skipProcessing: boolean) {
  if (skipProcessing) {
    return { skipped: true }
  }

  const userData = await fetchUserData(userId)
  return processUserData(userData)
}

Мои мысли: Всё просто: если что-то можно не делать — не делайте. Либо выполните что-то более полезное, либо просто сэкономьте ресурсы. Это правило применимо во множестве ситуаций, а не только в React/фронтенде.

---

Strategic Suspense boundaries
UI-оптимизация — layout показывается сразу, данные грузятся внутри

❌ Неправильно (весь layout ждёт данные):

async function Page() {
  const data = await fetchData() // блокирует всю страницу

  return (
    <div>
      <div>Sidebar</div>
      <div>Header</div>
      <div>
        <DataDisplay data={data} />
      </div>
      <div>Footer</div>
    </div>
  )
}

✅ Правильно (Sidebar/Header/Footer сразу; ждёт только DataDisplay):

function Page() {
  return (
    <div>
      <div>Sidebar</div>
      <div>Header</div>
      <div>
        <Suspense fallback={<Skeleton />}>
          <DataDisplay />
        </Suspense>
      </div>
      <div>Footer</div>
    </div>
  )
}

async function DataDisplay() {
  const data = await fetchData() // блокирует только этот компонент
  return <div>{data.content}</div>
}

✅ Продвинутый вариант (несколько компонентов используют одни данные):

function Page() {
  const dataPromise = fetchData() // стартует сразу, но не await

  return (
    <div>
      <div>Sidebar</div>
      <div>Header</div>
      <Suspense fallback={<Skeleton />}>
        <DataDisplay dataPromise={dataPromise} />
        <DataSummary dataPromise={dataPromise} />
      </Suspense>
      <div>Footer</div>
    </div>
  )
}

function DataDisplay({ dataPromise }: { dataPromise: Promise<Data> }) {
  const data = use(dataPromise)
  return <div>{data.content}</div>
}

function DataSummary({ dataPromise }: { dataPromise: Promise<Data> }) {
  const data = use(dataPromise)
  return <div>{data.summary}</div>
}

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