17-18.04 Был и выступал на MergeConf в Иннополисе. Прошлый год я пропустил, а в 2024 был дважды: в Иннополисе и в Москве. Так что впечатления – ожидаемые, конференция с качественными докладами и хорошим нетворкингом. В этом году нет афтерпати, это, конечно, жаль, но все равно, атмосфера – хорошая. Два дня, 11 треков, много мастер-классов и круглых столов. Так что я желаю организаторам успехов.

И один из круглых столов дал очень сильное впечатление, я бы сказал вау-эффект, хотя это не совсем точно. Это круглый стол по вайбкодингу в секции маркетинга. Секция – важно, потому что это – точка зрения заказчика, а не разработчика. Обсуждая заранее его с одним из коллег я выдвинул гипотезу о том, что говорить будут «Как же эти разработчики нас достали! Наконец-то можно без них!» И я угадал. Эксперты и участники в зале делились историями о том, как у них работает вайбкодинг, какие задачи получается решать. Главное – у них все работает. ИИ создает нужный софт лучше, чем разработчики. И умеет структуру, правда, специально просить надо, но это обучаемо. И не ноет. А при обсуждении задачи указывает на проблемы, и ты понимаешь, что с разработчиком бы это вылезло на третьей итерации в виде претензии «А че ты не сказал раньше?» И итераций до получения результата меньше, чем от разработчиков, и без дурацких вопросов. В общем, я сидел и записывал реплики, смотрите их в отчете, я начну именно с этого круглого стола.

Да, основной набор задач там все-таки касается не слишком сложных приложений. Но и не тривиальных. А про сложные говорили на других круглых столах и докладах, там тоже все неплохо. На круглом столе по ИИ у аналитиков один из участников, владелец аутсорсиговой компании, сказал, что он сильно сократил разработчиков: из 10 проектов они остались только на двух, а остальные 8 вайбкодят аналитики вместе с ним самим – он ставит процесс, разбирается с граблями и учит аналитиков их обходить. В этом круглом столе я был одним из экспертов, поэтому конспекта не будет: увы, конспект и участие совместимы слабо. И записи тоже, увы, не будет: Merge не делает записи, так было и на прошлых конференциях, у них такая позиция.

Из выступлений хочу отметить мастер-класс Максима Дорофеева, который был посвящен пониманию – как при передаче от одного человека другому, так и человеком самого себя, собственных планов. В мастер-класс было встроена игра, интерактивное обсуждение планов с другими, которое показывает, что за планом или другим высказыванием часто скрывается некоторая цепочка слов, смысл которого неясен даже самому автору. В коммуникации эта цепочка слов как-то интерпретируется другим человеком, и чаще всего смысл искажается или теряется, происходит «инъекция говна» – прикольный образ, иллюстрированный картинками. Интерактивную игру Макс создал вайбкодингом, и, как он говорил в кулуарах, раньше таких возможностей не было, был бы аналог на бумаге и других подручных материалах гораздо худшего качества. Кстати, у мастер-класса была очень интересная форма: вместо презентации Максим быстро вставлял рисунки и делал схемы в holst.so.

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

На этом общие впечатления я завершаю. Теперь – цитаты из круглого стола маркетологов и другие выступления на которых я был: сначала – по теме ИИ, затем – остальные. Их не так много, потому что три слота я выступал сам. и еще несколько пропустил выступления в польщзу нетворкинга. И, в любом случае, из всех 11 треков это малая часть.

Я тоже выступал: «DDD и современная архитектура: как проектировать модель и отражать ее в код (Merge-2026)». Конспекта моего выступления тоже не будет, но можно смотреть предыдущие, в статье есть презентация и ссылки.

Секция маркетинга, круглый стол: Вайбкодинг для всех: вымрут ли разработчики как динозавры?

Круглый стол на сайте

Формат стола – отдельные реплики и истории. Я это записывал. А общий смысл я уже передал: да здравствует вайбкодинг, он делает маркетологов незаивсимыми от разработчиков. Наиболее сильную цитату вынесу в начало, остальное – в порядке услышанного.

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

NoCode и LowCode – ограниченная коробка, это и минус, но и плюс по безопасности. Вайб-кодинг – любой полет фантазии, но дыры в безопасности, когда сливают учетки и кошельки – запросто. Поэтому полезно отдавать разработчикам на ревью, если есть такие риски.

Кейсы: сервис textprice – калькулятор для копирайтеров с обоснованием цены. И скрипт на питоне – чтобы названия файлов в Google-доке. Сопоставление было раньше вручную тяжелое, 50 файлов требовало несколько часов. А тут автомат, и еще ширину обрабатывает.

Делают сами, потому что отдел разработки всегда занят. О нем вообще не думали. Вообще было отношение, что внутренний редактор – надо просто принимать проблемы. А это можно изменить. Это ментальный переключатель. И вообще независимость от разработки – это вау! Разработчик – боль.

Реально сделать прототип ко второй встрече с клиентом. Или клиабельный прототип интерфейса в фигме. Самим. А еще они вытащили все материалы по всем роектам в общее хранилище, и ИИ отвечает на вопрос «что там с проектом». Но там – конвейер, чтобы сделать хороший ответ. И общее хранилище нужно, нейронка по 5-7 сайтам плохо бегает.

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

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

Опыт. Проверка кода после джунов требует большей тщательности, чем после ИИ. Но ИИ-шке надо было написать рекомендации – style guide. А для pet-проджект вообще код не смотрят. Но структуру дерева файлов все-таки смотрит. Хотя тоже не везде.

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

Кейс. Человек работает с ML в МТС. ИИ помогает в изучении алгоритмов, онбординге в новые процессы и проекты, разбирается со структурой БД, и еще куча задач – ЖКХ поругаться и так далее. Устроился в новую компанию, ему надо изучить проект, осмыслить. Но там Алиса и Gigachat, западные модели нельзя использовать, а наши – не тянут. Но по совету Gigachat скачал Llama и открытую модель DeepSeek – всего 7Мб. Поставил локально, отняло чуть больше часа. И дальше дал зарос на DeepSeek. Тот ушел в раздумья на 40 минут, но ответ – дал. И это на компе за 20тр. Ему это сэкономило 1-2 спринта онбординга в проект.

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

Кейс. Пару лет назад заключили контракт с одним банком. Штатный программист не тянул, он нанял студию, они год делали, до конца не сделали, но как-то сдали, 2.5м убытка. И по договору был, нужна была поддержка, у студии – комические деньги, он нашел одного fullstack-разработчика, тот тянул. Это история два года назад. А сейчас оявилась задача расширить, о спросил разработчика – и тот предложил переписать. И навайбкодил, весь преокт обошелся в 250 тр.

Ключевая роль человека – во-время чуть-чуть направить.

Игорь Рыбаков. Как мы перестраивали работу аналитика с AI

Выступление на сайте

Очень содержательный рассказ о поэтапном освоении ИИ для работы аналитиков, начиная с GPT-3 несколько лет назад.

• Чат – несколько лет назад, CahtGPT-3. Проект, где много use case расписать. Шаблонизировать типовые действия: use case, yaml, реестр требований, резюме встреч. Перспектива была, но отладка работы занимала больше, чем если бы писал сам – в знакомой области. А погружение в новую область было лучше и быстрее, чем через статьи.
• Развитие. Работу с чатом – совершенствовали, контекст больше. И рабочие схемы – формирование промпта, итерации размышления, направление. Роль, контекст, самопроверка, план выполнения, цепочка мыслей. Рабочие промпты под шаблоны use case, yaml, резюме встреч, user story, uat. Уже начало давать профит. И до сих пор 80% работы закрывается чатом с промптами.
• Диаграммы – PlantUML. Это замечательно. Диаграммы последовательности, c4, процессы, ERD, архитектура. LLM умеет создавать и умеет понимать твои диаграммы, это тоже профит. При этом диаграммы можно было связать между собой. Но работает только для системных артефактов – там нормировано. А с бизнесом надо неформально.
• Deep Research – погружение в новую предметку. ИИ умеет собирать информацию с инета, и переваривать несколько циклов. За несколько циклов можно много понять про заказчика – многие публикуют на хабре и форумах инфу. Workflow: Компания, Рынок, Предметка с проблемами, Гипотезы – подготовка первой встречи с экспертами. Половину vision можно собрать. Отдел аналитики начал получать профит. Разработчики – тоже.
• А вот HR и Менеджеры – первичное использование без системных промптов, у большинства сделать сложные промпты не получается. И они начали работать с агентами, чтобы дать им инструменты.
• Одно из достижений – сметирование: есть тендерное задание и надо за 5 часов дать оценку. Просто запихнуть в ИИ тендер – нельзя, будет много фантазий. Процесс: вводные данные по клиенту, сбор контекста и гипотез, вопросы и риски (MVP, релизы, требуемые доки), черновик структуры решений, передача на доработку. Вопросы зашиты в отдельные md, каждый такт проверяется человеком и дорабатывается. Запрос в мессенджер – агент выбрал сценарий – первый проход – результат в мессенджер – решение человека. И это – думающий алгоритм совместной работы. Сильно помогло в небольших процессах. При этом 80% закрывается чатом.
• ИИ для прототипа. Очень большой профит. Набросать экраны типа figma make – кликабельный прототип для заказчика. Постановка дизайнеру – сложно, но для первичного обсуждения с заказчиком-визуалом – ОК.
• Переход к новому формату работы. У каждого клиента – свои боли и свой способ работы: где-то фокус на интерфейсы, где-то cjm, где-то что-то другое. Понять архитектуру процесса может опять только аналитик. Поделили на блоки, начиная с интервьюирования. На блоки делит аналитик – ИИ не смогла взять. У каждого блока свой сценарий применения ИИ, у каждого вход и результат. Уровень привлечения ИИ различается – проекты разные. Я думаю, что поделить на блоки ИИ тоже сможет (как черновик), просто надо сделать грамотные промпты, это же достаточно нормированная тема – разделение работы на этапы в различных вариантах.

Итого. Каждый аналитик задает стратегию работ. Увидеть результат, Собрать процесс аналитики, определить, где подключать ИИ. Пока это в виде регламентов, и аналитик направляет ИИ, с системными промптами, но в принципе тут агенты тоже помогут.

Будущее – бизнес-запрос, функциональные блоки, AI и vibe-coding (пока он хорош для пет-проектов, но не для прома с большим контекстом), инженерные практики. И станет он ИИ владельцем информационной системы.

ИИ не заменит аналитика, он сам никогда так не думал – но он ускорит. Он поможет погружаться к предметку – и это надо уметь. Больше внимания надо уделить ценности. Фокус сместился в понимание процесса мышления – как мы получаем результат, какая цепочка приводит к нему – чтобы направить ИИ.

И коммуникация остается на человеке. 50% времени он работает психологом, процессы зашиты на конкретных людях. Даже если вы приносите идеальный результат – его надо продавать. И выманивать информацию – смотреть на невербалку, искать ходы в коммуникации. Впрочем, я думаю, ИИ тут тоже может помочь, например, если описать портреты людей, с которыми ты ведешь коммуникацию, и обкатывать на них сложные моменты, вырабатывать аргументы.

Решение вопросов – через взаимодействие с ИИ. Промпт не пишешь сразу хороший, так что его надо докручивать, а в моменте идти во взаимодействии.

Вопрос. Сколько внедряли, какой саботаж, какие метрики? Ответ. После испытательного срока остаются люди, которые понимают необходимость ИИ, так что саботажа нет. Сколько с нуля – не знаю, у нас процесс шел поэтапный, и каждый раз инкремент, да еще ограничение ИИ – два года назад было хуже. Сейчас можно форсировать, но эффект он не знает. Метрику снимал – количество задач. Персонал не сократился – высвободившееся время уходит на качество и позволяет снижать цену.

Вопрос. Как получается из аналитиков растить архитекторов ИИ? Ответ. То же самое, как с любым процессом. Группа евангелистов, которые продвигают и распространяют – как с любой практикой?

Вопрос. А галлюцинации? Ответ. Конечно есть. Решение – дорабатываем системный промпт. Как правило, при общении с бизнесом, там формируем в промпте границы. И еще разбивка на шаги, чтобы они стали более определенными.

Вопрос. Как побуждаете аналитиков? Ответ. Как с новым софтом. Всегда будет те, кто по-старому. Пропагандируем. И повышается требования за счет ИИ. Если он успешно решает задачи по-старому – и хорошо. Но если начинает отставать, а меняться не хочет, то показываем: уже джуны тебя обгоняют!

Сергей Бурцев. ИИ убьёт видеопродакшен? Мы проверили — и наняли вдвое больше людей

Выступление на сайте

Выступление – множество кейсов о мощи современного ИИ в создании видео, в докладе примеров реально много. Но, все-таки, полтора года назад на UIC.dev я видел гораздо более впечатляющее выступление Льва Бахарева «Ситуативный ИИ-контент: от брейнштормов к готовым проектам за минуты», у меня на сайте есть краткий конспект, но там интересно смотреть видео (надо подписаться на канал конференции). Возвращаюсь к выступлению.

Кейс. Строительная компания DARS 25 лет, надо срочно стать фильм. Интервью – да, но в кадрах нужна реальная стройка. А это зима, и стройка – не фотогенична. И генеративный ИИ – помогает. Реальный ролик, там смесь ИИ, видео из стоков и реальной съемки, и хорошо получилось.

2-3 года назад ИИ не было на таком уровне. Они по одному заказу делали заставку: зеленая горилла бегает по Москве, сравните – было печально по сравнению с нынешним уровнем. Но уже тогда круто по срокам и стоимости.

Есть проблема достоверности. Делали ролик про Симбирск, и показывали 17 век. Это очень сложно. Но возможно, просто надо уметь: убрать голливудский налет, использовать реалистичные планы местности, образцы архитектуры и одежды и много других деталей.

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

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

И это дает новые возможности, прежде недоступные. Кейс. Депутаты решили поздравить коллег с 8 марта – и сделали ситуативную юмористическую историю. Пиксаровские 3d-модели одних депутатов доставляют другим поздравления по модели города с разбитыми дорогами и другими препятствиями, которые тоже приземлены на реальные проблемы города. И озвучка идет полусинтезированным голосом.

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

Прототипы фильмов и роликов для разных тендеров запросто можно делать, это быстро, недорого и адекватно передает идею. Сделать видео картинка из Лондона 17 века для будущей игры – запросто.

Интересно, что поменялись сравнительные цены. Недавно самым простым было 2d, дороже 3d, а потом – реальные актеры. И ИИ – наоборот, проще – реальный человек, сложнее – 3d pixar, а 2d – еще сложнее. Недавно делали мультфильм про жизнь конкретного человека, как часть презентации к юбилею. Мультфильм – сложнее, чем видео.

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

В целом доля творческой работы возросла примерно с с 40% до 70%, ушла рутина. Пропал языковой барьер, они успешно работают на английском рынке без английских актеров, раньше это было невозможно. В профи-среде для крупных заказчиков видео не стало дешевле – они придирчивы к деталям как в классике. Но появилось больше возможностей. А в свободное время они делают рилсики про космос и на другие интересные темы – сейчас это просто.

Андрей Бровко из Авито. Spec driven AI. Как обеспечить качество?

Выступление на сайте

Мастерство ИИ в разработке растет. Есть бенчмарк SWE-bench, основанный на решении реальных задач из open source проектов, там начинали с 2% в GPT-4, в 32025 было 73-75% для Opus, а сейчас уже более 100%. И если год назад Карпатый говрил про вайб-кодинг, то в сейчас речь идет про Agentiс Еngineering, создание кода с помощью ИИ-агентов как регулярный инженерный процесс, мастерство в котором основывается на том, что мы понимаем, как рождается код и как его контролировать. И Андрей рассказывал про опыт использования ИИ-агентов в разработке Авито. Цель – удешевить и ускорить разработку.

При этом скорость конкретного опытного разработчика снижается: надо контролировать ИИ и давать задачи. А вот процесс целиком от внедрения ИИ ускоряется в 2-3 раза. Правда, количество уязвимостей от ИИ-агента больше в 2.7 раза, и с этим надо работать.

В 2025 были пилоты – группам инженерам давали подписки. На метриках роста производительности не видели, но и падения не было. А известно, что переход на новый инструмент, как правило, вызывает замедление – надо разобраться с тем, как он работает. Как результат пилотов, сейчас есть понимание, что работает и методика применения, а также централизованная база навыков. В планах масштабирование и внедрение в процессы,

Три секретных ингредиента.

1. Умная модель. Sonnet, Opus, Codex
2. MCP – интеграция с внутренними сервисами: доступность агенту документации и возможность ее обновления, доступ к коду и возможность поставить pull request, доступ к задачам в jira
3. Описание навыков – специфических особенностей компании: pipeline разработки, применяемые технологии, способы тестирования и так далее

Их pipeline Spec driven AI основан на разработке тестов до кода, это вариант TDD: спецификация (user story и acceptance) → Тесты → Тесты не проходят → Генерация кода → Тесты проходят.

Если детальнее, то получаются такие этапы, выполняемые ИИ-агентами и людьми по-очереди или совместно. - Задача в Jira в свободной форме - Трансформация в машиночитаемую форму по шаблону: цели, acceptance criteria и так далее. - Ревью продакта и инженеров - Декомпозиция задачи - Проектирование и наполнение техническими деталями - Ревью техлида - Генерация красных тестов (тест проверяет функционал, которого нет) - Ревью теста - Генерация кода - Автотесты зеленые - Чеклист ручной проверки. Его может создать агент – он знает тонкости раеализации - Ревью кода - Релиз в тестовом окружении - Тестирование - Релиз в прод - Мониторинг работы

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

Для организации pipeline есть фреймворки для этого. Они смотрели

• SecKit – тяжело и надо вычитывать
• Superpower – там проще, есть такт брейнсторминга, а тесты вперед, используют его

Инженер не печатает код, а ставит задачу, валидирует и принимает результат. Разработчики тоже иные. И QA – модель может написать автотесты, а его роль – стратегия качества, SDLC и CI/CD, настройка агентов, аудиты качества и так далее. Пока трансформация не произошла, но туда идут.

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

Человек проводит ревью тестов – они становятся частью спецификации, в каком-то объеме ревью кода, но его становится очень много. Тут нужна помощь агентов – их надо учить. Приемочное тестирование – агент не слишком хорошо представляет пользовтелей, работающих с продуктом. А еще – проверка артефактов агентов, инструкций и тулов. И проверка безопасности и учет особенностей LLM.

Ближе к концу был забавный слайд. Оказывается, Роберт Мартин предлагает выбрать 3 характеристики из 4: Скорость, Бюджет, Качество, Объем, и говорит, что все четыре недостижимы. А в свое время говорили про проектный треугольник Быстро – Хорошо – Дешево и говорили, что достижимо лишь два любых. Wiki говорит, что концепция восходит к 1950-м, а автор неизвестен. Сначала я подумал «вау, прогресс, научились достигать все три». А потом понял, что проектный треугольник рисовали при неизменном скоупе (объеме) проекта, а сейчас им тоже начали управлять. Впрочем, нормальных подтверждений концепции нет, в реальных проектах сплошь и рядом получается медленно, дорого и плохо одновременно.

Как они делают сравнение разных моделей? Через тесты и метрики. Используют внутренние и внешние метрики, метрики эффективности (DORA- пропускная способность против нестабильности). На слайде были выписаны, но в целом там понятные и широко используемые метрики процесса разработки, никакой ИИ-специфики нет. Экономически использование агента окупается уже при 4% ускорения – разница месячной подписки и зарплаты разработчика громадная.

Реально эффект больше, но отделить фактор ИИ от остального – сложно. Потому что производительность разработки в Авито растет уже много лет, и резкого увеличения на графиках нет. Однако на конкретных типах задач видно ускорение, например, отчет, который раньше отлаживался бы человеком полчаса-час, агент с доступом к данным по MCP делает за пару минут.

Риски.

• Agent shadowing – он копошится, а вы не смотрите вообще. Он может копошиться очень долго.
• Безопасность и governance
• Риск утечек персональных данных и коммерческой тайны
• Ускорение без контроля качества превращается в ускоритель разработки техдолга.

Поэтому в pipeline – и люди и агенты, и это должна быть содержательная, а не формальная конструкция. Цитата: «если архитектура, тестирование и релизный процесс слабые ИИ-агент ускоряете поставку дефектов». Отмечу, правда, что это громкое заявление – от компании, которая берет деньги за наладку процессов, так что они – предвзяты, и борются за свое место в условиях массового распространения ИИ.

Вопрос. Как убедили ИБ использовать модели вне контура компании? Ответ. Это было непросто, и повезло, что руководитель увлекается идеей ИИ. Но есть условия: какие домены можно выносить во вне, а что крутить только на внутренних моделях, есть сервисы анонимизации для выноса наружу или даже предоставления моделям доступа, есть разметка в документа«noAI».

Насколько сильная модель нужна? Они начинали несколько лет назад с малых моделей, там контекста не хватало, эмпирически вычислили, что надо минимум 32к. Сейчас это есть, и уже начинается обратная проблема: в контекст можно запихнуть очень много, и модель расфокусируется, теряется в том, что ей сказали. Надо следить.

Максим Дорофеев. А кто сказал, что у человека интеллект не искусственный?

Выступление на сайте

Это был рассказ о проблемах понимания. Не только про искажения передаче другим, но и о том, что человек часто сам плохо понимает, что говорит. Даже когда пишет свои планы. Он просто плетет цепочки из слов. И это не просто рассказ – была интерактивная игровая демонстрация этого эффекта. Правда, я был только в начале: мастер-класс был два слота, а я после первого ушел выступать сам. Так что рассказ в сокращении.

Предположим вы сидели на докладе. В конце вопрос: «Поняли? – Вроде да!» А как вы поняли, что поняли, если еще ничего не сделали?

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

Почему не сделал задачу? – Не успел! – Надо было расставить приоритеты!

Звучит умно, но что все-таки надо было сделать иначе – не ясно. Глупые люди тоже умеют говорить умные слова. Вот если бы умение говорить умные слова разблокировали только с дипломом, и ты не мог сказать «дофамин», если не понимаешь, что это такое – жизнь была бы лучше.

Замечу, кстати, что в Китае дело обстоит именно так. В школе ты учишь 2-3 тысячи иероглифов и не сразу, а постепенно, есть график освоения по классам. А потом, вместе с освоением программы ВУЗа, ты учишь иероглифы, которыми записываются понятия из твоей специальной области. А пока не выучил – ты просто не можешь прочесть профессиональные статьи. Написать и сказать тоже не можешь.

Своими словами мы описываем не вещи или явления, а свой опыт их восприятия. Многие люди говорят о вещах и явлениях, и думают, что про них. А это – про восприятие. «Эта книга плохая» – нет, это говорящий думает, что книга плохая. Почему он так решил, мы не знаем. Он взял книгу, почитал, подумал, и не нашел ничего нового, или прочитал фигню – это его оценка. Может быть проблема в книге, может в восприятии, может быть в осмыслении. Где по пути была инъекция говна, которая испортила оценку – мы не знаем. А некоторые люди могут вообще не читать книгу, а сложить мнение из того, что он услышал другого. В уши испражнялись и ты передаешь. Оценивал ли ты источник. Сейчас вариант «читал в пересказе ИИ», ИИ же хорошо пересказывает – а это тоже неточно.

У Максима не было презентации, а была доска в holst, где он быстро рисовал картинки, или копировал из заготовок. Я не знаю, оставит ли он доступ, так что одну картинку я оттуда заберу на память.

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

«Гарри Поттер и методы рационального мышления», цитата. Гермиона: «Почему у людей не получается стать собой?» – Поттер: «Мы уже сами, а не чьи-то копии. Но если отвечать в духе вопроса: то это происходит потому, что люди набираются всякой ерунды и бездумно ее повторяют». А Бернейс в книге «Пропаганда» (1928) заметил: «Когда-то думали, что грамотность даст человеку возможность мыслить самостоятельно. А реально всеобщая грамотность дала человеку не разум, а набор штампов, приправленных рекламой. Он у людей одинаковый, и потому у них будет одинаковый отклик при воздействии – так работает пропаганда».

Штампов много. Но главный вопрос в передаче: что передают широко, а что – не популярно. Выпустили мессенджер и все говорят, что он – плохой. И вопрос не в мессенджере, а в том, как это появилось и как передали. Штампы – как закэшированная страница, и плохо, когда кэш не актуален.

Но дело не только в передаче. Люди очень часто вяжут умные цепочки слов без логики и наполнения смыслом. Типичный план жизни выглядит примерно так: «Я закончку универ, потом … эээ … будет много разного, а вот потом – я живу за границей в огромном доме и у меня много денег». Середина, которая должна провести от начала к концу – отсутствует. И это – не преувеличение, так мыслит большинство.

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

Чтобы показать, что люди плохо понимают – интерактивная игра. Заодно по результатам Максим обработает, чтобы понять – где именно дыры у людей сейчас.

Игра устроена так. Каждый пишет свой план в формате «Я планирую что-то для того чтобы было вот это, по итогам чего достигну цели, которой хочу». Например, так: «Я планирую получить диплом магистра, для того чтобы устроиться на крутую работу, по итогам чего накоплю на первый взнос на ипотеку». Дальше идет объединение в пары или тройки – каждому, кто написал план – назначаются 1-2 душнилы, которые видят план и пишут вопросы. Для душнил есть шаблон, чтобы не уходили в сторону: они выделяют конкретное слово, и дальше есть шаблоны вопросов для каждой части речь – существительного, прилагательного, глагола. Потом – такт обсуждения вопросов. И игровая механика с баллами, которые игроки ставят себе и друг другу, оценивая, насколько люди понимают, что говорят.

Пока шла игра, Максим приоткрывал планы и вопросы. Там по-разному. Где-то – формально, а где-то реально по содержанию. А дальше я, увы, ушел.

Кирилл Морозов. Мифы о поколениях: доказательный менеджмент

Выступление на сайте

Основное сообщение доклада: перестаньте использовать теорию поколений! В 2010-х, то есть уже 5-10 лет назад, была серия исследований, которая на статистике показала: на статистике теория не подтверждается. А у нас ей продолжают учить, и ловят хайп темы «как работать с зумерами». И ладно бы просто учили, но ее потом используют для построения систем управления и мотивации персонала, и получается фигня, которая наносит реальный вред. А также еще ее активно используют для оправдания: «Почему закрыл вакансию? – Так я – зумер!» или так: «Почему у тебя уволился сотрудник? – Так он – зумер, поколение такое».

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

А теперь подробнее. В самом названии «теория поколений» – обман. Это – не теория, а концепция. Нет критериев, по которой она является теорией. В мире уже говорят больше с точки зрения опровержений, а к нам она докатилась и хайп ловят темы «как работать с зумерами».

Концепт, который лежит в основе, такой: людей можно делить по годам, которые привязаны к значимым событиям, и все люди, попадающие в один интервал (поколение) мыслят и действуют одинаково. Почему?

• Люди одного возраста переживают общие события – развал СССР, Великая Отечественная, или их аналоги в Штатах – великая депрессия, подъем 1960-х.
• Опыт формирует уникальные базовые ценности и привычки. Зверства бельгийцев в Африке – рубить руки за невыполнение плана. Когда на глазах у отца рубят руку ребенку – повлияли на африканцев. А вот на бельгийцев в далекой Бельгии – нет.
• Верно, что травмирующий опыт оставляет следы – но он оставляет следы и на ребенка и на ветерана. Идея, что нельзя выкидывать хлеб – у всех переживших войну.

Что можно взять из этих концептов? Значимые события действительно влияют на людей. Только влияют они по-разному: в 90-е одни накапливали капитал, а другие – выживали и у них – различное отношение, и различный опыт. Так что деление по поколением удобно, но чрезмерно упрощает.

В презентации – несколько ссылок на научные исследования, которые показывают, что корреляция между поколением и характеристиками поведения, включая производительность труда – отсутствует, и в целом разница по производительности труда у людей разного возраста ничтожна. Можно уверено утверждать, что год рождения не формирует уникальный код человека. По всему миру – все по-разному.

Почему теория поколений она вредна?

• Если мы принимаем, что она работает, то принимаем, что есть зумеры и миллениалы, и мы работаем с ними по-разному – две системы мотивации, управления и так далее. А при большем разбросе возрастов в компании надо еще больше систем делать. Если так поступают, то получается дискриминация по возрасту, которая реально приносит негатив.
  

• Теория используется для оправдания. Человек таков, потому что родился в конкретный год, и не виноват в этом: «Почему закрыл вакансию? – Так я – зумер!» или «Почему уволился сотрудник? – Так он – зумер, поколение такое».

Я тут замечу, что теория поколений – реальна фигня. Наблюдения над относительно небольшой социальной группой в США обобщили на весь земной шар без всяких оснований и начали продавать как готовые рецепты. Но машина впаривания серебряных пуль работает. Так что разоблачение теории поколения – это как разоблачение рекламы или пропаганды. Если человек с мозгами, то он и так не поверит, а если без мозгов – то вряд ли поможет. Но все равно, если в результате выступления ей меньше станут верить, то оно полезно.

Что же реально надо учитывать?

• Есть эффект возраста, возрастные динамики. Черчилль: «Если в 20 лет не либерал – у него нет сердца, а если в 40 лет не консерватор – нет мозгов.» Только учитывать, что в разных социальных группах возрастные динамики проявляются по-разному. Черчилль говорил о конкретном слое британских джентльменов. А если смотреть сейчас, то чем человек моложе – тем свободнее в своих воззрениях, у него меньше привязок и он легче меняет работу.
• Есть эффект глобальных событий, и не только войн или кризисов, как 90-е, но и развития технологий: появление смартфонов без кнопок, соцсетей и так далее.
• Эффекты интерферируют: возраст влияет на реакции на событие.

Что изменилось сейчас?

• Появилась удаленка, ковид дал опыт всем, люди попробовали и это – не отменимо.
• Нет ведра с крабами. Крабы не выбираются из ведра, потому что их другие затягивают.
• Легкий переход между компаниями у молодежи: нет накопленного багажа, сильно работает интерес. У него тоже в 20 лет не было проблем со сменой работы, а сейчас стал разборчивей.
  

• Поведение будет изменятся с возрастом, но мир не поменяется обратно.

Что все хотят? Справедливая оплата труда, признание и адекватный руководитель. Это – база, которую надо обеспечить. И дальше будет только хуже.

Кирилл не раскрыл, почему раньше эти требования были не обязательны. Мое мнение – рынок труда перешел от профицитного, на котором работодатель диктует условия, к дефицитному, на котором условия диктует специалист, именно он выбирает работодателя. Да, есть ситуативные колебания, и в моменте в ИТ идет сокращение проектов и люди ищут работу, но это – кратковременно, так происходит регулярно в соответствии с экономическими циклами меняется точка равновесия. А вот переход к дефицитному рынку – долговременный тренд, это следствие перехода от физического труда к умственному, при чем такому, где человеческий фактор имеет решающее значение. Это хорошо показано еще у Друкера более 25 лет назад: в его Энциклопедии менеджмента есть отдельный раздел про тренды будущего и даже отдельная книга «Менеджмент. Вызовы 21 века». Он предупреждал, что такое будущее наступит, и раскрывал механизмы. И вот оно наступило. А в ИТ про ключевую роль человеческого фактора писал Том ДеМарко еще в 1980. Все это – старые новости.

Каждое из требований Кирилл подробно раскрыл.

Справедливая оплата труда.

• Прозрачные правила: сотрудник четко понимает метрики и алгоритм повышения зарплаты. Понимать, за что платят. Во многих компаниях этого нет. Хороший вопрос: спросить сотрудника и руководителя «за что зарплату платят» и сравнить результат
• Фокус на результат: компания оплачивает реальные навыки и закрытые задачи. Удаленка породила индивидуальный капитализм: подработки или работу на нескольких местах.
• Отсутствие предвзятости – без эйджизма и другой дискриминации, а то «зумерам все, а милениалам – ничто?» Одна прозрачная система управления. Если в корпкультуре принято ругаться матом, то собирайте таких сотрудников, нет проблемы. Но подсвечивайте на входе и понимайте, что не все пойдут. Если руководитель в цеху ругается, то и на собесе нет смысла на собеседовании демонстрировать приличное поведение.
• Рыночный уровень зарплат – аналитик (и другие) реально сверяет ставки с конкуретнтами. Бренд влияет на ствки в разные стороны.

Конечно, настраивать все это сложнее, чем просто сказать «зумеры не хотят работать».

Признание.

• Регулярная обратная связь. Не раз в месяц. Практика: «сделай – прокукарекай» в рабочем чате – и это лайкают сразу.
• Публичное одобрение – руководитель выделяет результаты перед всей командой. Пикборд перед кабинетом руководителя, например.
• Внимание к идеям: никто не знает бизнес, чем вы сами. И есть направления, где сотрудники разбираются лучше. И поэтому их идеи будут ценные. Главное, чтобы они начали говорить. Клиника Фомина: есть план роста бизнеса на идеях сотрудников, и это у них существенная часть прироста бизнеса.
• Доверие к экспертизе – свобода действий, прежде всего – право на ошибку.

Адекватный руководитель.

• Четкие задачи: есть цель и она каждый день не меняется. Эффективная команда: есть цель и все в команде понимают одинаково. «Нам надо нанять продавца» – HR приводит BizDev, enterprise-продавец, а идея была – обработка потока входящих заявок, их много. Потому что цель проговорили абстрактно.
• Честная коммуникация: когда кризис – не скрывать. И про хорошую тоже рассказать. Это снижает уровень стресса, они из режима выживания и тревоги переходят в режим продуктивной работы.
• Защита от стресса – это выделил отдельно, хотя связано в предыдущим.
• Развитие вместо контроля, наставник помогает расти. Это – по желанию, если предыдущие выполняются.

Михаил Усов из VK. Хайпкодинг: вчера, сегодня и завтра языков программирования

Выступление на сайте

В выступлении – личная история и размышления о том, стоит ли менять языки, изучать новые, и по каким причинам. Основной посыл: не стоит гнаться за модой или деньгами, а надо менять, если устал или стало скучно и ты хочешь изменений. И изменения – не обязательно смена языка, можно пойти вглубь, в изучение фреймворков и механизмов, в Java полно таких возможностей, и в других языках – тоже.

Я бы сказал, что в чем-то это – антитренд: не идите в ширь (T-shape), копайте вглубь (I-shape). И, возможно? это действительно уместно, потому что часть людей идет вширь, вообще не вырастив ногу, а скользя по поверхности. Впрочем, еще есть деление людей на дайверов и сканеров от Барбары Шер, и она говорит, что сканер – это тоже нормально.

У него знакомство с программированием началось в детстве, с книги «Энциклопедия профессора Фортрана» – концепция описания алгоритма на примере чистки картошки была интересна и произвела впечатление.

Я замечу, что на одном из ЛАФ на афтерпати была командная игра для аналитиков: одна команда писала другой инструкцию, как приготовить сэндвичи из набора продуктов (хлеб, колбаса, сыр, все в упаковках), а другая их выполняла. Побеждала та команда, которая написала инструкцию, в результате выполнения которой сэндвичи получились больше похожими на идеал. У многих команд сэндвичи получились не съедобные – «пункт снять целофан» для какого-нибудь ингредиента забывали массово, не говоря уже о том, что масло надо размазать, а помидор – порезать. Но вернемся к выступлению.

В 5-6 классе была информатика, Турбо-Паскаль. Но тогда не увлекло. Осознанный выбор был позднее – php, чтобы писать динамические сайты. Самый популярный тогда. Был еще Perl, но он уходил. Учебник был на CD, и вместе с ним – дистрибутивы для развертывания у себя. Выбирать язык самому понравилось больше. А потом перешел на Java, обучился тоже сам.

Сегодня самый популярный – python, держит лидерство около 5 лет. Еще JavaScript и Java. А по сайтам вакансий после python – sql. Но на рейтинги опираться не стоит.

Правда, почему не стоит опираться на рейтинги, Михаил не объяснил. Выбор php был ошибкой? И зачем он про них рассказывал несколько слайдов в этом случае, тоже не понятно.

Я бы тут сказал следующее: реальный выбор всегда касается определенного класса задач или области работы: есть enterprise, автоматизация корпораций и банков, есть public web – соцсети, маркетплейсы и смежные задачи, есть ML и анализ данных, и так далее, областей много. В каждой области – свои языки, свои типы задач, своя культура разработки. И выбирать надо направление работы в комплексе. В этом смысле Михаил был прав с php, если динамические сайты – то, что нравилось.

Дальше был тезис, что мнение, будто за один язык платят больше, чем за другой – миф. Он в свое время именно поэтому пошел на Java. Впрочем, что это было ошибкой Михаил явно не сказал. Он перешел к рассуждениям про публично публикуемые уровни оплат, где лидирует Objective-C, и указал, что рейтинги не надежны, потому что не у всех вакансий указана зарплата.

Я тут опять укажу на типы задач. На Objective-C пишут драйверы и другой системный софт, этап работа требует высокой квалификации и потому стоит больше. На Java решают самые разные задачи, и спектр зарплат поэтому очень широкий. При этом на Java есть сегмент разработки в корпорациях, где платят больше не за язык, а за согласие работать в условиях токсичных политических игр. И так далее. То есть главное все-таки направление работы и классы задач, а язык – вторичен.

Языки не умирают. PHP – жив. Не стоит гнаться за новым, опасаясь, что твой – умрет. Многим языкам 15+ лет, даже тем, которые полагают «новыми».

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

Как стать сеньором? Просто не увольняться! Через 5 лет большинство уйдут, а вы станете экспертом. Но я отмечу, что это было сказано в эпоху вечных проектов, а сейчас велика вероятность, что проект закроют и ты окажешься на рынке с никому не нужными устаревшими знаниями. Я знаю таких людей, им было тяжело перестроиться.

Сергей Иванов из Aston. Инженерия доверия к событиям: как мы ловили и закрывали дыры в гарантиях Exactly-Once после 3 месяцев продакшена

Выступление на сайте

К сожалению, у меня не получилось послушать доклад с начала. А он был на важную тему. Дело в том, что, вопреки наивным представлениям многих людей, протокола, который бы обеспечивал точно exactly once не существует. Бывает at least once с возможным дублированием сообщений, или наоборот, at most once с их возможной потерей. В некоторых средах ты можешь это настраивать на уровне потока сообщений, в других есть только поведение из коробки.

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

Основная мысль выступления: учитывайте эту особенность и предусматривайте мониторинг и средства разбора. Простого применения паттернов недостаточно. Например, ведите на отправителе и получателе счетчики, и разбирайтесь, когда они разъезжаются. Это – очень правильная мысль,

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

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

Проблема в том, что многие техлиды уверены: всегда приходит корректные события, все линии надежны. И приходится преодолевать их сопротивление. Это подтверждаю.

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

Выступление на сайте

Основной посыл выступления в том, что функциональное программирование – способ мышления и набор принципов, который можно реализовывать на многих современных языках программирования, он туда встроен как один из вариантов, наряду с императивным. Это было показано в примерах на OCaml, Scala, Python, JS и Rust, а на github у Павла лежат примеры еще на 11 языках вместе с песочницей, где все это можно развернуть и пощупать, в презентации была ссылка.

Функциональное программирование основано на алгебре лямбда-исчисления Черча, разработанной в 1930-е. И тогда же была их совместная статья с Тьюрингом, где было обоснована эквивалентность лямбда-исчисления и машины Тьюринга, то есть потенциальная выразимость любой программы в этом формализме.

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

В любом языке есть малые функциональные фрагменты – выражения, которые могут быть сложными и оформленными в виде функций, работающих только с локальными переменными. Но на ранних языках программирования (Fortran, PL/1, Algol) этим ограничивалось, более сложные конструкции нельзя было представить, требовались циклы и работа с глобальными переменными и массивами. И были отдельные языки, как LISP в которых вместо циклов можно было использовать рекурсию, а сами функции представляли собой объекты, на которые можно было ссылаться и делать на их основе другие объекты. На LISP я не работал, но дорабатывал систему генерации документации Schema и много работал с разными xsl-генераторами, так что опыт подобных языков есть, не считая fluent-выражений в современных языках, о которых речь пойдет дальше.

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

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

Таким образом, современные языки – гибриды, они смешивают разные парадигмы. Пионером гибридного языка, сочетающего процедурную, объектную, функциональную и реляционную парадигмы стал C# 3.0 (2008). Авторы преследовали сугубо прагматичную задачу: научиться в прикладном коде включать фрагменты SQL-операторов в языковые конструкции на объектном языке нативно, то есть оперируя объектами языка, но чтобы втянуть реляционную парадигму потребовалось еще и функциональная. С тех пор еще подтянулся синтаксический сахар обеспечивающий комфортную работу с акторами и реактивное программирование – набор парадигм еще увеличился. Но теоретики до сих пор не освоили это достижение инженеров, и продолжают бороться за чистоту конкретного использования, говоря «фу» на гибриды, например, функции с сайд-эффектами и состоянием.

Но вернемся к выступлению. Павел показал ряд примеров функциональной работы на разных языках, идеи достаточно похожи. Это fluent-модель записи выражений, когда мы берем коллекцию объектов и далее начинаем на нее накладывать различные условия, проводить агрегации и так далее. При этом на каждом шаге получается производная коллекция, исходная не модифицируется – в отличие от классической обработки в цикле. А оптимизированный компилятор или виртуальная машина языка обеспечивают, чтобы эти вычисления были относительно эффективны, а не превращались в перекладывание громадных массивов данных. Но дальше все упирается в возможности этого оптимизатора и ваш способ написания, тут дело обстоит примерно так же, как с SQL-операторами выборки сложных данных. Впрочем, вопросы эффективности были за рамками выступления, примерчики были простыми.

Примеры были на пяти языках и была краткая характеристика.

• OCaml – язык богов, но лучше Haskel. B гуманный, не для ученых.
• Scala – Ocaml с другим синтаксисом и поверх JVM.
• Python – для младших научных сотрудников, не для промышленного использование, но он оказался удобен для широкого класса задач. Так же, как Perl придумали для обработки больших текстов, а он понравился и сделали общим языком.
• JS – самый функциональный из нефункциональных.
• Rust – в нем много из функционального мира.

И были примеры, иллюстрирующие функциональный способ решения.

• Считаем сумму скидок для заказов дороже 100, у которых скидка 10%. Не цикл по заказам, а fluent-выражение – последовательный набор фильтров по условиям и свертка.
• Считаем сумму четных чисел – аналогично.

В python важно понимать, что далеко не все является выражением, можно писать функционально, а можно – императивно.

Дальше примеры про работу с функциями в функциональных языках. Фишка в том, что функция является объектом, и мы можем передать ее как аргумент в другую функцию, получить композит. Когда у нас фильтрация или агрегация идет не явно заданным образом, а с помощью функции, передаваемой как аргумент. Это концепт HOF – high order functionб и мы можем не просто вызвать функцию, но преобразовать или обернуть ее: сделать замыкание – захват лексического окружения или каррирование – сделать из функции от трех аргументов трех функцию из двух, зафиксировав один из аргументов.

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

Пример работы с функциями – определяем функцию над элементом и применяем ее к списку. Содержательно это можно применять для вычисления налогов: отделяем вычисление конкретного налога или комиссии от функций, обрабатывающих коллекции документов и сделок. На OCaml это пишется коротко, Scala – длиннее, нужны сигнатуры каждой функции и в Rust – тоже. А вот python требует специальной библиотеки. И JS тоже, нужна ramda.

Правда, не знаю, про python, а про смысл rambda в JS я не понял. Работая над конспектом я бегло посмотрел статьи с примерами, и утверждения о том, что «код получается чище и понятнее» мне кажутся надуманными. На мой взгляд, примеры с rambda наоборот, читаются хуже и требуют дополнительных знаний.

Чистая функция – когда значение зависит только от аргументов, и ничего не изменяет – нет побочных эффектов. Это важно для многопоточного программирования, получается независимость от порядка вычислений и параллелизм. И был пример для работы со скидками – чистая и не-чистая функция.

Иммутабельность. const/val – запрет перезаписи переменной. Мы должны либо дисциплиной либо средствами языка сделать так, чтобы нечто не меняло свой внутренний мир. Это становится важным, когда мы работаем с большими структурами – коллекциями, списками, деревьями, и делаем цепочку преобразований над ними. Формально на каждом шаге получается дубль с какими-то малыми изменениями, а задача – обеспечить такую оптимизацию памяти, чтобы этого дубля не было, а были лишь изменения, и при этом еще сохранился оригинальный вариант, если он где-то продолжает использоваться. На тему, как именно это обеспечить написаны докторские диссертации. Подробности можно посмотреть в книге Окасаки «Чисто функциональные структуры данных».

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

А потом кейс практического применения функционального мышления, он интересен. Речь была именно о мышлении в функциональной парадигме, а не конкретных языках. Есть система на Ruby on rails, сделанная и много лет развивавшаяся ad-hoc. Ее надо разобрать на сервисы. Идея состоит в том, чтобы выдергивать оттуда код и укладывать в pipeline.

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

На каждом шаге к success-сценарию еще добавляются побочные ветки ошибочных сценариев разных классов, это тоже важно и явно видно. А граница между успехом и ошибкой – пунктирная, она зависит от трактовки запроса: «сделай это» или «попробуй сделать это», на схемах это было. Например, при резервировании товара под заказ, если смогли из 3 единиц зарезервировано две, можно рассматривать как успех, хотя и не полный, или как провал. А вот если прервалась связь или сервис упал и ответ не получен – это точно ошибка.

В реализации мы опираемся не на active record, а иммутабельное dto (транспортный объект). Команда – функциональный объект, call с bind – монадное связывание «и если все хорошо – связываем». А fail – идет возврат быстрый. DO-нотация на yield вместо обычной дает иллюзию императивного программирования. Команда-функция возвращает Success или DomainError – иммутабельный value object.

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

А в заключении конспекта я хочу пару абзацев сказать про декларативное программирование. Павел активно о нем говорил, поскольку функциональное программирование принято считать частным случаем декларативного. Есть таксономия, где на верхнем уровне – деление программирования на императивное и декларативное. В императивном мы пишем машине инструкцию по шагам – что делать, а в декларативном – определяем результат, а дальше машина как-то сама его достигает. Граница проведена в 1960-е, и там было все понятно: Fortran, PL/1, Algol – императивные языки, инструкции для машины, транслируемые в ассемблер и далее – в код. А LISP, поскольку вовсю работал с рекурсивными вызовами и большими списками, которые в лоб в императивные команды не транслировались, требовал более умной реализации. В 1972 за LISP пришел Prolog с идеей «мы опишем мир в виде логических утверждений, и компьютер сам сможет решать задачи» – именно так в то время понимали ИИ. А в 1974 – SQL, реализующий реляционную парадигму работы с базами данных, его операторы работают с большими массивами данных, и реализация требует сложных преобразований. И вроде все логично.

Но дальше языки начали смешиваться: компиляторы Фортрана начали проводить крутую оптимизацию, сопоставимую с SQL, в C появились указатели на функции, что расширило использование функциональной парадигмы внутри императивного языка, появилась перегрузка функций по сигнатуре и динамическая типизация, разметка текстов для подготовки документов, позднее – декларативные описания для экранных форм, а рост производительности и памяти позволил разворачивать работу с массивами в циклы без особой оптимизации и так далее. Парадигмы смешивались, и деление языков на императивные и декларативные, проведенной в 1960-е потеряло содержательный смысл. Но, поскольку оно зафиксировано в академических работах, то по-прежнему присутствует.

А вот парадигмы программирования – процедурная, объектная, функциональная, реляционная и акторная – по-прежнему несут содержательный характер, это определенный подход к мышлению. И есть еще декларативный подход, когда мы задаем систему правил или описание структуры, а дальше идет их интерпретация. Чаще всего это относится к конкретным обрластям. Например, я делал прототип в виде бессерверного приложения в броузере, где декларативно описывалась геометрия витрин торгового зала магазина и система правил выкладки обуви на этих витринах, а система порождала конкретную выкладку с учетом наличия обуви в магазине. И приличная часть кода там была в функциональном стиле, fluent-выражения над коллекциями. Кстати, прототип пошел в пром и проработал три года, прежде чем этот функционал включили как составную часть в большую систему.

Но можно делать не только конкретные приложения, но и фреймворки. Описываем типы справочников и документов и графы переходов документов между состояниями, а на выходе получаем полу-готовое приложение с таблицами структурами в базе данных, таблицами документов в интерфейсе с фильтрами для работы и формами для заполнения, а также кнопками вызова переходов для обработки документов. Понятно, что нужна еще содержательная логика, помимо CRUD, и она может быть подключена на любом языке в рамках тех же деклараций. Или включена внутрь на скриптовом языке, как в html встроен JScript.

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

Наиля Галимова из Билайн. Data QA: преодолевать хаос в данных и не сойти с ума

Выступление на сайте

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

Чтобы разобраться с этим, стартовали большой проект Data Governance, частью которого было внедрение системы Data Contract – контрактов на поставку данных.

Нельзя сказать, чтобы интеграция была не описана вообще. Для большинства были описания в confluence, но при этом актуальность их была неизвестна, и далеко не всегда обе команды знали про это описание. Поэтому нужно было что-то более надежное, чем статьи в confluence.

Рассматривали две системы .

• SODA – там есть дата-контракты, можно проверять, настроить под себя. YAML-файл с параметрами поставки.
• Data Catalog – там тоже есть контракты. Если если туда втянуты описания корпоративных данных – то просто накликать контракты. И это – понятнее, чем YAML-файлы.

Выбрали Data Catalog.

Два уровня описания описания.

1. Условия поставки данных – соглашение от поставщика широкому кругу, что он может выдать.
2. p2p-контракт – это договор между поставщиком и потребителем.

Пока они причесывают то, что есть, описывая первый уровень.

Условия поставки включает описание структуры объекта данных, глубину хранения и регламент обновления, а также владельца данных и группы инцидент-менеджмента. И идет контроль с алертами. С обновлением данных есть важные нюансы: одному потребителю может быть важно время обновления, а другому – полнота получаемых данных. И надо, чтобы система это подсвечивала.

Они сделали платформу, провели пилот. Для пилота искали лояльных – тех, кто устал от вечных проблем. Встраиваются в roadmap, дают инструменты с низким порогом входа, self-service платформу, и ИИ-агентов для помощи. Сейчас масштабируют, в компании накопилось очень много витрин – помогают приоритизировать.