🧑‍💻 AI: зачем нужны структуры данных для JavaScript — практические примеры для бэкенда и фронтенда

Структуры данных в JavaScript обычно объясняют через их внутреннее устройство, API и оценку сложности Big O. А мы пойдем от реальных инженерных проблем: написание бизнес-логики, кода на JavaScript и TypeScript для backend и frontend, типовые проблемы в разработке: коррапт глобальных данных, гонку состояния, очереди, кеширование, история изменений, управление памятью и ресурсами.

Мы разберем, почему каждая структура решает определенную проблему, и уже как следствие, то что она что-то запрещает и чем за это приходится платить, но и какие плюсы мы получаем. От обычных Array, Object, Map и Set до Linked List, Persistent List, Heap, Circular buffer, Bloom filter, Stack, Queue, Append-only, Immutable lists and Records. Отдельно классифицируем структуры для доменного, продуктового, платформенного и системного кода.

https://www.youtube.com/live/qNAjrZ07un0

Новый набор в гильдию Next Tick

За что тебе платят, когда код пишет модель? Ответ, с которым мы работаем в Гильдии: за работу с ограничениями, decision framework, архитектуру, review, широкое мышление, глубокую экспертизу, умение коммуницировать с людьми и агентам.

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

Некоторые темы по архитектуре, которые мы уже рассмотрели:
- AI и архитектура: кто кем управляет, зачем уменьшать сложность
- Почему "большие задачи" почти всегда ложь — и как дробить работу
- Вертикальные слайсы vs горизонтальные слои в архитектуре
- Acceptance criteria как проверяемый контракт
- Planning for AI: explicit outcome, границы, definition of done
- Не весь техдолг равен, как продать рефакторинг на языке ROI
- Rewrite vs refactoring, AI-assisted migration: где AI ускоряет, а где производит новый долг
- Мифология в программной инженерии
- Architecture review: что реально должно блокировать merge
- Реактивные вычисления, модель акторов, конечные автоматы
- Мультипарадигменное программирование и построение DSL-языков
- Функциональные и нефункциональные требования
- ADR (документирование архитектурных решений)
- Управление характеристиками кода для построения нужной архитектуры

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

Что будет в ближайшее время:

- Как архитектурное ревью меняют продукт и команду
- Архитектурные границы и проектирование контрактов
- Нужных людей невозможно нанять. Их нужно выращивать
- Как развиваться на работе, а не деградировать
- Как влиять на коллектив через идеи, идеи сильнее приказов
- Как наладить менторство в коллективе и в чем его цель
- Risk assessment: как думать о том, что может пойти не так

Архитектура - это пересечение экономики и эстетики: предсказуемость из непредсказуемых частей, обратимые решения vs one-way doors, R&D вместо "надо все знать".

Заходите на сайт, там обзор и описание формата - https://nexttick.it/?utm_source=timur_tg_howprogworks

В NextTick мы регулярно проводим голосовые разборы для участников с платной подпиской. Один из последних стримов мы решили ненадолго открыть в Telegram-канале IT-Гильдии.

AI уже умеет ускорять разработку. Проблема в том, что бизнесу не нужен код быстрее. Ему нужны решенные задачи.

Это часовой разговор о том, что агентская эпоха уже меняет в работе разработчика: почему количество сгенерированного кода ничего не говорит о результате, где сохраняется ценность инженера и почему архитектура, code review и способность спорить с неверными решениями становятся важнее скорости написания кода. А еще — что изменения в GitLab, увольнения в Cloudflare и рост AI-рынка означают не для абстрактного «рынка труда», а для конкретного разработчика прямо сейчас.

Запись будет в канале до 2 августа. https://t.me/itguild_next_tick

Почему в JavaScript мире нет культуры использования структур данных?
Их неправильно учат, точнее, правильно, но этого мало, такие знания полезны только на задачках с литкода и на собесах, а вот на практике люди сразу забывают про структуры данных и реальный код только: [], {}, Set, Map

Я поискал, как их обычно преподают
- как устроены внутри и как работают
- как оптимизировать: CPU, memory
- как оценить вычислительную сложность
- как оптимизировать под V8, GC

Но нет даже попыток показать:
- как применить на реальной задаче
- как они делают код понятнее
- как они помогают экономить на AI

1 августа покажу примеры на реальном коде для бизнес-логики, системного программирования, бекенда, фронтенда: https://youtube.com/live/qNAjrZ07un0

Курс Ильи Климова «Тестирование в эпоху агентов»

AI уже умеет писать много кода, но без тестов, контрактов и автоматической проверки качества он завалит вас кодом и вы его даже не вычитаете, не говоря уже о том, что на глаз многие вещи просто не ловятся, особенно в таких объемах кода. Курс учит, как построить управляемую инфраструктуру, чтоб тестирование помогало дресировать AI. Особенно полезно тем, кто уже использует AI в реальных JavaScript/TypeScript-проектах.

Промокод на 15% ti15 до 1 августа

Заходим, не стесняемся: https://ai.javascript.ninja/gld-ai-r

Как вы думаете, кому выгодно, чтобы вы не читали код и чтобы он все время переписывался и никогда не стабилизировался? One-shot? Все с нуля и каждый раз - вот что нужно. Все свои софты личные, одноразовые тулы, agentic loop, self-review, Best-of-N, infinite repair, full-replay...

Под стримом по структурам данных задали вопрос, какие AI модели я использую и какой харнес.

Отвечаю развернуто, но вы должны понимать, это моя специфика разработки

Я стараюсь по неделе переключаться между моделями, чтобы знать их состояние и чувствовать особенности, но для моих задач сейчас лучше всего подходит Sonnet 4.6 (даже не 5), Codex 5.3, Grok 4.5, они не очень умные, но мне не нужно, чтобы они были умные, за то они не придумывают хитрых и запутанных решений и работают очень быстро. Вот в тех же структурах данных я их все пробовал использовать и пришел к выводу, что они примерно все на одном уровне, если применять их для текхической рутины. Они делают именно то, что просишь, особенно если сбрасывать контекст часто, хотя и деградация у них ниже, чем у флагманов.

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

Но Fable 5 и Opus 5 я обычно использую для другого, чтобы они сделали альтернативное моему решение и чтобы сравнить со своим, т.е. они хороши не как вспомогательный персонал, а как самостоятельные авторы и какие-то идеи у них можно брать, хоть я обычно и выкидываю их результат, потому, что они заводят код в глухой тупик очень быстро из-за того, что умные и дерзкие.

В субботу 8 августа мастер-класс в 17:00, покажу тем, кто зарегистрируется https://gm.nexttick.it/go/data-structures-code-review

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

AI ошибается. Люди тоже ошибаются.

Проблема в том, что AI производит код полный недочетов и скрытых ошибок быстрее, чем чинит и в большем объеме, чем человек способен прочитать.

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

Нужно уменьшать стоимость проверки результата и стоимость владения.

Промпт не является контрактом. Это пожелание на естественном языке, допускающее десятки интерпретаций. Можно написать модели "не ломай совместимость", "учти все крайние случаи" и "пиши надежно", но эти фразы невозможно автоматически проверить. Контракт должен быть формальным и желательно исполняемым.

Типы фиксируют форму данных, сигнатуры и архитектурные границы. Это дешевый, широкий, но неглубокий контроль. Типы не подтверждают бизнес-логику, порядок операций, права доступа, транзакционность, идемпотентность, отсутствие гонок и корректность побочных эффектов. А в TypeScript типы вообще не являются точным описанием того, что будет реально исполняться в виртуальной машине. Типы стирается до runtime и виртуальная машина сама выводит свои типы, которые отличаются от того, что вы себе написали в TS.

Типы описывают представление компилятора о программе, а виртуальная машина работает с реальными значениями у которых есть вычислимая "форма" и с кодом, кторый оптимизируется во время исполнения под эту форму. Данные всегда приходят из сети, БД, JSON, JavaScript-модуля, пользовательского ввода и не соответствуют тому, что было в TS. Типы в рантайме более строгие, чем в TS, например, он учитывает порядок полей в объекте, знает, как резолвится асинхронная функция, через ивентлуп или очередь микротасков, отличает значения внутри Number: HeapNumber, Smi, Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Float16, Float32, Float64, Word8, Word16, Word32, Word64...

Более того, TypeScript сознательно не является полностью sound-системой типов. Он допускает операции, безопасность которых невозможно гарантировать статически. Поэтому типы полезны как дешевый статический фильтр, документация и компактное описание архитектурной границы. Но они не подтверждают, что программа действительно выполняет контракт. Для этого нужна runtime-валидация, ограничения данных и тесты наблюдаемого поведения.

Тесты фиксируют поведение гораздо точнее. Мутационное тестирование намеренно портит реализацию чтобы проверить общую стабильность на сломанном пути. Контрактные тесты подтверждают совместимость модулей и сервисов Интеграционные тесты проверяют взаимодействие с базой, сетью и инфраструктурой. E2E фиксируют наблюдаемое пользователем поведение. Нужно зафиксировать даже неизвестное legacy-поведение, а как это сделать типами?

Полная типизация внутренней реализации постепенно теряет смысл, AI способен читать реализацию целиком и отслеживать реальные рантайм-типы гораздо более точно. Во многих проектах достаточно JavaScript для реализации каждого модуля + d.ts для контрактов. Typings становятся суммаризацией кода и документации. Они описывают обещание модуля внешнему миру, не заставляя потребителя изучать реализацию. Внутри можно свободно менять алгоритмы, структуры данных и декомпозицию, пока сохраняются внешние типы, тесты и инварианты.

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

Заходим к Илье, учимся тестировать с AI: https://ai.javascript.ninja/gld-ai-r