Будни аналитика

После того как локально всё заработало, наступил момент истины — выкатить ReadBot в настоящий интернет, туда, где он будет жить своей жизнью, пока мой ноутбук выключен. Утро началось с подготовки. Александр в режиме FSD выдал 702 страницы анализа: нужен Universal Source рефакторинг, чтобы один источник мог работать и в режиме чтения, и в режиме анализа. Антон расписал план из девяти блоков. Макс начал катить — модели, миграции, роутеры, API-клиент для бота. Гриша проверял каждый блок и говорил APPROVED...

Хотел сделать простую вещь: задеплоить Telegram-бота на сервер. Бот рабочий, тесты проходят, код написан. Казалось — дело на полчаса. Не вышло. --- Сначала отпал Hetzner — они перестали принимать паспорта из России ещё после 2022-го. Пришлось искать альтернативу. Остановился на Railway: git push — и деплой. Это удобно, инфраструктуры минимум. Но Railway — это Docker. А в Docker у меня сразу возникло несколько проблем. Первая: Claude Code CLI, который используется внутри контейнера, отказывается работать под root...

Финальная часть серии. Мы прошли интеграции, архитектуру, базы данных, SQL и диаграммы. Сегодня закрываем блоки, которые проверяют на каждом собеседовании без исключений: требования, методология разработки, тестирование, безопасность. В конце — краткий итог всей серии. Сохрани этот пост вместе с предыдущими тремя — это полный чеклист подготовки от Junior до Senior. ──────────────────────────────────────── ▶ Требования: ФТ и НФТ Первый вопрос на любом уровне — чем отличаются функциональные требования от нефункциональных...

Третья часть серии. Первые две были про интеграции, архитектуру и базы данных. Сегодня — практический блок: SQL запросы, которые пишут прямо на собеседовании, и нотации для описания процессов. На собеседовании системного аналитика SQL пишут руками. Не объясняют теорию — пишут конкретный запрос. К этому нужно быть готовым. ──────────────────────────────────────── ▶ SQL: от простого к сложному Уровень Junior — базовый синтаксис: Простой запрос — это первое что спросят: SELECT * FROM users WHERE active...

Продолжаю серию о подготовке к собеседованию на роль системного аналитика. В первой части разобрали интеграции — REST API, SOAP, брокеры. Сегодня переходим к архитектуре и базам данных. На собеседованиях эти темы идут парой: сначала тебя спрашивают про монолит и микросервисы, потом про нормализацию и транзакции. Если знаешь оба блока — ты уже сильнее большинства кандидатов. ──────────────────────────────────────── ▶ Архитектура: от Junior до Senior Уровень Junior — базовое понимание: Архитектура...

ЧЕКЛИСТ СИСТЕМНОГО АНАЛИТИКА: КАК ПРОЙТИ СОБЕСЕДОВАНИЕ ОТ JUNIOR ДО SENIOR. ЧАСТЬ 1 — ИНТЕГРАЦИИ ==================================================================================================== Я три года провожу собеседования и сам через них прошёл. Вот что реально спрашивают у системного аналитика — от первого вопроса джуниора до задач, которые ставят в тупик мидла. Это первая часть серии из четырёх постов. Каждый пост — отдельный блок знаний с конкретными вопросами и ответами. Сегодня разбираем...

У меня 7 AI-агентов. Каждый знает свою роль, помнит прошлые задачи и работает в команде с другими. Вот как это устроено — не теория, а конкретная структура из живого проекта. --- Начну с главного заблуждения. Агент — это не промт в ChatGPT. «Ты — опытный программист, помоги мне с кодом» — это не агент. Это просто инструкция для одного разговора. Агент — это участник процесса с ролью, памятью и правилами. Разница в том, что агент помнит контекст между сессиями, знает о проекте больше чем вы написали в этом сообщении, и работает по правилам которые вы установили один раз...

💡 Что такое AI-агент и чем он отличается от ChatGPT Большинство людей думают что AI-агент — это просто умный ChatGPT. Разница — принципиальная, и когда она становится понятна, меняется то как вы вообще думаете об автоматизации. --- ChatGPT — это транзакция. Вы задаёте вопрос, получаете ответ. Следующий вопрос — новая транзакция. ChatGPT не помнит что вы обсуждали вчера, не знает о вашем проекте ничего сверх того что вы написали прямо сейчас, не умеет читать файлы на вашем компьютере или запускать код...

💡 Почему AI-агент не заменяет разработчика? Разбираемся У меня 7 AI-агентов. Они пишут код, тесты, документацию, промты для контента, делают ревью. И ни один из них не может заменить разработчика. Вот почему — и почему это нормально. --- Первый аргумент, который я слышу: «AI пишет код, зачем тогда программист?» Я сам так думал, когда начинал собирать команду из агентов. Прошло несколько месяцев реальной работы — и картина оказалась сложнее. Агент делает то, что ему сказали. Не то, что нужно. Конкретный пример из моей практики...

83 теста, 4 сессии, 0 перепутанных постов Изначально ReadBot делал одно: загружаешь книгу — он режет её на посты и публикует в твой Telegram-канал. Один человек, одна книга, один канал. Всё работало, и для личного инструмента этого было достаточно. Потом появился второй пользователь. А вместе с ним — главный вопрос мультипользовательской архитектуры: как гарантировать, что посты одного человека никогда не попадут в канал другого? --- Когда проектируешь мультипользовательский Telegram-бот, самая болезненная ошибка — не падение сервера и не медленная работа...

Ольга начала редактировать. И всё изменилось. Когда я впервые запустил ReadBot, Ольга была проверяющей. Компрессор сжимал текст, отдавал ей готовый результат, она ставила оценку fidelity и говорила: REDO или OK. Простой контроль качества на выходе. Казалось — достаточно. Но я смотрел на цифры после первого реального теста. Восемь постов получили REDO. Восемь раз компрессор переделывал работу с нуля, потому что только в конце узнавал что пошло не так. Как строить дом, а потом ломать стены потому что архитектор посмотрел на готовый этаж и сказал — не так...

После релиза v1.0 я открыл backlog — там было полно идей от проджект-менеджера, но когда я писал ему задачи, то обращался просто "PM" или "менеджер проекта", и что-то в этом было мёртвое. Как будто я разговариваю с роботом-секретарём, а не с человеком. Я сидел и смотрел на список агентов: аналитик, разработчик, тестировщик, ревьюер, архивариус. Все они делали свою работу, но я не мог представить их как команду. Они были функциями. Модулями. Скриптами с описаниями ролей. И тут я подумал: а что, если дать им имена? Не красивые AI-клички типа "АрхиМастер 3000", а обычные человеческие имена...