Системный сдвиг

IT хоронят уже лет пятьдесят как минимум. Помните академика Ершова?

«Для программистов наступают трудные времена, стартапы тают, программисты пополняют армию безработных, а саму профессию перестают считать особенной» — это 1972 год, а звучит так, будто написано на прошлой неделе.

Похороны повторяются каждые 10-20 лет: новая технология, модный фреймворк, low-code, no-code, а теперь еще AI-агенты всех нас заменят. Но есть фундаментальные вещи, которые остаются необходимыми для успешного проектирования и разработки систем:

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

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

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

Что внутри:
🔸 Сетевые протоколы и технологии интеграции
🔹 Производительность и надёжность: кеширование, балансировка, способы масштабирования
🔸 Инфраструктура: Docker, Kubernetes, Service Mesh
🔹 Выбор хранилища данных, репликация и шардирование
🔸 Консистентность, управление транзакциями, оркестрация и хореография

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

🔗️️ Подробности и отзывы без цензуры смотрите на сайте, а сегодня еще действует ранняя цена.

Курс идёт по субботам с 14 ноября по 19 декабря

Реклама. ИП Бураков Андрей Олегович.
ИНН 632133429581

И вдогонку к предыдущему посту: конечно же, самые сложные места даже в простой системе — очередь задач и интеграции. (А очень часто очередь задач как раз и стоит перед интеграцией).

Ну, казалось бы: получил файл + описание, передал в LLM, получил результат (это так в этой системе).

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

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

Соответственно, на каждую из проблем есть лечение:
* перепосылки (на удаленной системе начинают задваиваться данные / дважды запускается расчет / наша система зацикливается в бесконечных перепосылках)
Лечение для лечения:
- уникальная идентификация запросов
- ограничение числа перепосылок

* Синхронизация схем данных с версионированием (реестр схем, обсуждение между системами готовности предоставлять данные в определенном формате определенной версии)

* Промежуточные сохранения и запуск процесса с середины (не запускать заново процесс расчета, если он ранее проведен и входные данные не изменились)

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

И это я ещё про гонки запросов не написал...

Я закончил первую очередь небольшого проекта, который разрабатывал один при помощи ИИ. Не хочется говорить — вайбкодинга, потому что вайб — это, ну, сел, запилил быстро какую-то идею. Тут скорее речь про AI-SDLC: ну вот просто так сейчас устроена разработка, не людьми, а нейросетями.

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

И знаете, что? Офигенно!

Раньше я бы такой проект оценил минимум в полгода и минимум 3-4 разработчика (+тестировщик, +девопс). Мне хватает Курсора с подпиской Pro. При этом не нужно синхронизировать всех людей и их задачи. А ещё не нужно убеждать разработчиков сделать что-то, что выходит за рамки их привычного фреймворка. Например, у меня в проекте есть три кастомных компонента для полей формы, за каждый программисты мне попили бы крови: в фреймворке такого нет, это не стандарт, это будет плохо работать и т.п. ИИшка безотказная — надо, значит надо. А ещё её не напрягает и не пугает объем работы, она замечательно может протестировать этот компонент во всех вариантах и краевых случаях: когда мало элементов, когда много элементов, когда список пуст; на узких экранах, на мобилке, с выключенным JS и недогруженным CSS, с увеличенными/уменьшенными шрифтами, со скрин-ридером и контрастной чб-схемой и т.д. RTL мне не понадобился, и на том спасибо. В общем, обычно программисты такому резко сопротивляются.

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

Систему взял специально небольшую, чтобы я мог её сам держать под контролем:
6 ролей
6 внутренних модулей + очередь задач + внутренняя ИИ-модель
~45 сценариев
около 50 экранов
25 таблиц, примерно 15 справочников
Парочка огромных форм ввода на 30+ полей
7 интеграций: 3 внутренних и 4 внешних
Штук 6 объектов со своими состояниями + правила их переключения

В функциональных точках получается примерно 300-400, это довольно типовой размер проекта на 4-6 месяцев для небольшой веб-студии.

Что заметил за это время, пишу вперемешку про плюсы и минусы:

1. ИИ проще всего написать одну функцию / один законченный модуль. Вообще никаких проблем, всё пишет + тесты. Если хорошо поставлена задача. Как только какие-то места недостаточно конкретно прописаны, ИИ их либо срезает, либо наоборот — начинает вырастать лишнее, чего не нужно. Лишнее приходится обстригать, срезанное — доращивать. Это не очень напрягает, потому что происходит быстро. Дольше фиксировать в спеке.

2. С дизайном у меня не очень получилось. Говорят, Claude Design в этом хорош, у меня не было под рукой. Ну, то есть, какие-то общие подходы удалось найти, но иногда новый агент теряет и дизайн, и даже CSS-фреймворк, это нужно фиксировать и следить. В общем, понадобился дизайнер, чтобы придать некоторую консистентность внешнему виду.

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

4. Так же, как и человек (а может даже хуже), ИИ принимает некоторые решения без обсуждения и анализа. Иногда он попадает — когда мне лень ему подробно расписывать задачу. Иногда принимает решения, которые мне не подходят. Это не его проблема, он ведь не обладает всей полнотой информации. К счастью, почти все такие решения можно быстро откатить / переделать. Главное, вовремя о них узнать — тут стоит просить его показывать предположения, на которых он основывался, и решения, которые принял. Как найти подходящий уровень фиксации, я пока не понял: всю мелочь контролировать не хочется, по-верхам есть шанс что-то пропустить. Впрочем, это всплывает на тестах.

И ещё один момент: время создания начинает упираться в готовность заказчика рассматривать результат и давать обратную связь. Если сесть рядом и быстро разбираться, можно очень быстро всё сделать. А если заказчик готов на демо раз в неделю — это и будет ограничением. Ну и пока заказчика один на один с ИИшкой не оставишь, нужен "оператор ИИ" :)))