IT – Гильдия

Одна маленькая правка потребовала изменений в пятнадцати местах

Задача выглядела простой: добавить новый статус заказа.

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

Одно место пропустили — клиент получил уведомление по уже отмененному заказу.

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

Так часто происходит из-за флагов

В объект добавляют:

isPaid
isCancelled
isRefunded

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

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

Код работает. Но каждое изменение становится дороже предыдущего.

А разве AI не может исправить все места?

Может найти похожие условия и быстро внести правки. Но AI не всегда знает, какое правило автор проекта держал в голове и какие связи не описаны в коде.

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

Скорость редактирования не исправляет архитектуру.

Что делает инженер

Он не начинает с поиска всех if. Сначала выясняет:

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

После этого пятнадцать разрозненных условий превращаются в один источник правды и несколько понятных вызовов.

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

🔥 Поиск работы в 2026: рынок стал жестче. Но что с этим делать?

В Гильдии NextTick мы обсуждаем много интересных тем и вот на днях подняли вопрос «3к мало или норм» для разработчиков с 5–7 годами опыта и уперлись в более широкий вопрос:
как сейчас вообще искать работу, когда вакансий мало, а требования растут?

Контекст довольно жесткий.
В 2024 году технический отбор мог доходить до вопросов вроде особенности типов системы.
В 2026 многие просто получают отписку: «у нас шквал заявок».
У знакомого аутсорсера ротация людей упала с 75% до 15% — люди просто сидят и не рыпаются.
При этом рынок все чаще хочет фуллстеков и «единорогов» с уникальным опытом.
Чистый backend-профиль могут отсеять еще на скрининге:


«Вам интересен бек, а нам нужен фуллстек».
И здесь возникает вопрос: что делать разработчику?

Обсудили несколько рабочих подходов.
1. CV нужно тейлорить под вакансию.
Не отправлять один универсальный файл на всё подряд, а показывать именно тот опыт, который нужен конкретной компании.
Даже Claude можно использовать для этого: надиктовали свои реальные кейсы — получили разные версии CV под маркетинг, гемблу или generic. По итогам — «вышло довольно хорошо».

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

3. Pet-проекты — спорная тема.
Для среднего аутсорсера писать петы действительно может быть «такое себе развитие».
Но если речь про небольшую бутиковую команду до 20 человек, pet-проект может стать тем самым фактором, который отличит одного кандидата от другого.
И главное — pet нужен не только ради GitHub.
Это возможность потрогать технологии, которых нет на основной работе, расширить кругозор и получить материал, о котором потом можно нормально рассказать на собеседовании.

Но самая интересная часть обсуждения была про фидбек после собеседований.
Частая реакция после отказа:
«Спрашивают какую-то ненужную многопоточность и классы. Отбор какой-то бредовый».

Если конкретная компания использует эти вопросы как фильтр — значит, для нее это валидный сигнал.
Да, условный LeetCode может не пригодиться вам в ежедневной работе.
Но если через него компания отбирает людей — это часть правил игры.
Поэтому вместо «у них какой-то бредовый отбор» можно задать другой вопрос:
«Что я не смог ответить и почему?»
И после каждого собеседования закрывать обнаруженные пробелы и брать ответственность.

А как вы сейчас чувствуете рынок?

Рассказали, что будет во второй части мастер-класса, но не назвали главное — когда встречаемся 🙂

Уже завтра, 8 августа, в 17:00 по Киеву Тимур продолжит разговор об архитектуре и структурах данных.

Подробности и ссылка на эфир:
https://gm.nexttick.it/go/data-structures-code-review

Добавляйте в субботние планы

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

Скилы тут: https://github.com/metarhia/metaskills

Три связанных скила, которые помогают AI оптимально использовать встроенные структуры, писать кастомные, и использовать структуры из metautil

1. js-data-structures - выбирает между встроенными структурами JavaScript: Object, Array, Map, Set, WeakMap, WeakSet и TypedArray. Учитывает семантику, сложность операций, стабильность V8-структур, утечки памяти и границы сериализации.

2. data-structures - нужен, когда встроенных коллекций недостаточно. Он помогает выбрать или реализовать очередь, дек, стек, связный или развернутый список, кольцевой буфер, кучу, trie, граф, LRU, pool, CRDT или персистентную структуру.

3. metautil-data-structures - знает точный API готовых реализаций из metautil и может сразу использовать их в проекте вместо генерации очередного велосипеда.

Реализации структур со стрима:

- Все структуры из metautil: https://github.com/metarhia/metautil
- Struct для типизированных mutable и immutable записей: https://github.com/metarhia/metautil/blob/main/lib/struct.js
- Иммутабельный ConsList со структурным разделением, ветвлением состояния и откатом за O(1): https://github.com/metarhia/metautil/blob/main/lib/cons-list.js
- Префиксное дерево Trie: https://github.com/metarhia/metautil/blob/main/lib/trie.js
- Двусвязный List с операциями вставки, удаления, перемещения, группировки и сортировки: https://github.com/metarhia/metautil/blob/main/lib/list.js
- Развернутый список UnrolledList для высоконагруженного FIFO: https://github.com/metarhia/metautil/blob/main/lib/unrolled.js
- Кольцевой буфер, на котором построены Queue, Deque и Stack: https://github.com/metarhia/metautil/blob/main/lib/circular.js
- Очередь Queue: https://github.com/metarhia/metautil/blob/main/lib/queue.js
- Двусторонняя очередь Deque: https://github.com/metarhia/metautil/blob/main/lib/deque.js
- Стек Stack: https://github.com/metarhia/metautil/blob/main/lib/stack.js
- Пул ресурсов: https://github.com/metarhia/metautil/blob/main/lib/pool.js
- Семафор для ограничения конкурентного доступа: https://github.com/metarhia/metautil/blob/main/lib/semaphore.js

Установка скилов из корня проекта: npx metaskills

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

«Выбери подходящую встроенную структуру данных»
«Подбери структуру для этой нагрузки и объясни выбор»
«Реализуй очередь без Array.shift»
«Перепиши управление состоянием с использованием ConsList из metautil»
«Используй готовые структуры metautil и не создавай собственные аналоги»

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

Как пользоваться скилами я покажу на 2 части мастер-класса.
Там же будут и разборы примеров использования в реальном коде: https://gm.nexttick.it/go/data-structures-code-review

Последние места в Гильдии заняли меньше чем за 60 минут

Если вы откладывали решение, скрин выше может немного испортить настроение 😄

Участник пришёл в Гильдию с SPA «на коленке». За первый месяц подключил Stripe, открыл платную подписку и превратил приложение в законченный продукт, который можно показать на собеседовании.

Никакой магии: приложение он сделал сам. Но знания из лекций не остались лежать в папке «посмотреть потом» — они сразу пошли в работу.

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

Сейчас войти уже нельзя.

Чтобы в следующий раз не ловить race condition за свободные места, открываем предзапись.

Заполните короткую анкету — и вы:

— первыми узнаете дату следующего набора;

— получите ссылку на вход раньше, чем она появится в канале.

Предзапись ни к чему не обязывает.

👉 Встать в предзапись

‼️ ВНИМАНИЕ, СПОЙЛЕРЫ ‼️

Если вы слушали вчерашнее голосовое от Ильи, то наверняка заметили, что он немного проговорился. 👀

Да, мы действительно готовим следующий большой этап развития Гильдии.
Скоро)

Здесь мог бы быть ещё один длинный пост о Гильдии, но после голосового Ильи это было бы лишним — все уже сказано😄

Поэтому коротко:
сегодня закрываем текущий набор в Гильдия NextTick.
Готовы принять ещё 20 участников — как только места займут, доступ закроется.

Дату следующего набора пока не назначили. Точно знаем, что в августе набора НЕ будет.
Если собирались присоединиться — переходите в бот🔥

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

Материалы из стрима по структурам данных

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

➜ Исходники и примеры использования структур из metautil: https://github.com/metarhia/metautil
➜ Struct и иммутабельные структуры: https://github.com/HowProgrammingWorks/Immutable
➜ Префиксное дерево Trie: https://github.com/HowProgrammingWorks/Trie
➜ Примеры разных списков: https://github.com/HowProgrammingWorks/List
➜ Очереди https://github.com/HowProgrammingWorks/Queue
➜ Конкурентная очередь: https://github.com/HowProgrammingWorks/ConcurrentQueue
➜ Double ended queue: https://github.com/HowProgrammingWorks/Dequeue

Насколько далеко вы ушли от [] и {}? 👀

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

🔥 Собираетесь смотреть вживую — поставьте реакцию.

👉 Открыть трансляцию и включить напоминание

Как защитить рефакторинг, который назвали «нейрослопом»

🧩 Что случилось

Участник Гильдии несколько недель рефакторил экран: обновил дизайн, подключил новое API, исправил старые баги, добавил тесты и документацию.

Получилось два больших MR. В первом — 3200 новых строк и 1800 удалённых. Из добавленных строк 1700 приходились на тесты, ещё 200 — на документацию.

Рефакторинг согласовали заранее. Участник обозначил риски, но во время работы они не реализовались. Казалось, задачу можно заканчивать.

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

Участник пришёл в технический чат Гильдии с вопросом:

«Я потратил кучу времени, чтобы превратить спроектированный нейронкой код в задокументированный, структурированный и разбитый по небольшим файлам. В чём я не прав?»

🔍 Что разобрали в Гильдии

В обсуждении отделили две проблемы.

Первая — техническая. В одном изменении соединились рефакторинг, новое API, новый дизайн и исправление старых багов. Такой MR трудно проверить, даже если большая часть новых строк — тесты и документация.

Вторая — переговорная. Предварительное согласование задачи не гарантирует, что результат примут. Право на финальное решение всё равно остаётся у лида.

Участнику предложили не доказывать, что код хороший, а задать два вопроса:

— Что конкретно не устраивает в текущем решении?
— Что можно исправить, чтобы продолжить ревью?

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

✅ Чем всё закончилось

Через два дня участник вернулся с результатом.

MR решили влить для релиза. Затем изменения откатят и внесут заново небольшими частями. Участник дополнительно проверит код, исправит неточности и перепишет документацию по принципу «человек для человека».

На будущее команда договорилась разбивать MR объёмом больше 500 строк.

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

Но работу не выбросили. Вместо «закрываем всё» появился план, с которым согласилась команда.

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

💬 Если вы тоже хотя бы раз приносили на ревью огромный MR, а потом жалели об этом, поставьте реакцию. Посмотрим, сколько нас таких.

🎙 Послезавтра, в субботу, — открытый стрим Тимура: «AI: зачем нужны структуры данных для JavaScript — практические примеры для бэкенда и фронтенда»

Приходите.

⏳ P. S. Осталось три полных дня — 31 июля, 1 и 2 августа, — чтобы попасть в закрытую Гильдию NextTick.

👉 Узнать, что внутри Гильдии

Не читать AI код?
Может еще на дорогу не смотреть когда машину ведете?
Есть другой экономный путь

Как вопрос в чате превратился в бота за два часа 🤖

Сегодня в 12:22 в чат Гильдии NextTick прилетел обычный вопрос.
Человеку лид поручил написать RFC на внедрение Playwright — а опыта с RFC ноль.
«Поделитесь, кто сталкивался, что вообще должно быть внутри?»

Илья ответил: «у нас же прямо видео есть» — и скинул ссылку.
А через пару сообщений добавил фразу, с которой всё и началось:

«вы мне идею подали».

Дальше — самое интересное. Идея не ушла в «когда-нибудь потом».
В 14:34, спустя чуть больше двух часов, в чате появился ОН — бот, который знает всё, что публиковалось в Гильдии.
Тегаешь его в сообщении — он идёт по всей базе: постам, разборам, записям стримов — и отвечает по делу, со ссылками.
Илья тут же выложил, как он его собрал, — с кодом и всей внутрянкой.

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

— Дай рецепт борща.

— Рецепт борща не относится к базе знаний этого чата — здесь посты Гильдии про архитектуру, коммуникации и работу с AI-агентами.
По кулинарии не подскажу. А вот по теме — с радостью.

Казалось бы, всё. Но нет:

— Какая архитектура лучше всего подходит для приготовления борща, какие есть нюансы в коммуникации с капустой и как отвечать свёкле на комментарии в merge request?

— В материалах Гильдии нет рецептов борща, и свёкла там тоже не комментирует merge request'ы 🙂 Это база знаний по архитектуре ПО, AI-агентам и командной коммуникации.
Если интересует что-то реальное — могу подсказать, как выстраивать коммуникацию («Обратная связь, которую слышат») или как ревьюить AI-код («Ревьюим AI-код»).

Бот не только не повёлся на буряк в мерж-реквестах — он ещё и вежливо развернул разговор обратно к делу и подкинул ссылки.
С характером и на языке вопроса.

Мораль дня простая: между «а поделитесь опытом» и работающим инструментом в проде прошло два часа.
Вопрос → идея → бот.
Так теперь у Гильдии NextTick есть собственная память — и её уже можно тегать🔥