Договорись с ИИ. Часть 2 Реальные проекты, профессиональные практики и продвинутые возможности Claude Code

Зачем нужен личный кабинет

Многие проекты, в отличие от простого сайта-визитки, подразумевают, что у каждого пользователя есть своя, персональная область — история заказов в интернет-магазине, личные напоминания в боте, заявки клиента в системе учёта. Это требует двух вещей, которые мы пока рассматривали только теоретически (в главе 3 и в первой книге): базы данных для хранения информации разных пользователей и системы авторизации, чтобы каждый видел только своё.

В этой главе мы создадим личный кабинет для нашего третьего сквозного проекта — системы «Учёт клиента» для условной мастерской по ремонту техники, но описанный подход одинаково применим и к личному кабинету покупателя интернет-магазина.

Шаг 1. Формулируем задачу с учётом ролей

Хочу сделать систему учёта для мастерской по ремонту техники.

Нужны две роли:

1. Администратор — видит всех клиентов, все заявки, может

создавать и редактировать записи

2. Мастер — видит только заявки, назначенные лично ему,

может менять статус заявки (в работе / готово)

Начни с регистрации и входа: страница логина с email и

паролем, после входа — перенаправление в зависимости от роли

Обратите внимание на явное разделение ролей прямо в формулировке задачи — это гораздо надёжнее, чем добавлять разграничение прав задним числом, когда система уже частично реализована без учёта этой структуры.

Шаг 2. Как устроена регистрация и вход технически

Полезно понимать общий принцип происходящего, даже не вникая в код. При регистрации пользователь вводит пароль, но сохранять его в базе данных «как есть», обычным текстом, — серьёзная и распространённая ошибка (если база данных когда-либо окажется скомпрометирована, все пароли пользователей будут немедленно раскрыты). Вместо этого пароль преобразуется необратимым математическим способом (это называется хешированием) в бессмысленный на вид набор символов, и именно этот набор сохраняется в базе. При каждой попытке входа введённый пароль точно так же преобразуется и сравнивается с сохранённым хешем — если совпадают, значит, пароль верный, при этом сам исходный пароль нигде, кроме момента ввода пользователем, не хранится.

СОВЕТ: Не нужно самостоятельно разбираться в деталях алгоритмов хеширования — это ровно тот случай, когда достаточно знать общий принцип и доверить реализацию Claude Code, который по умолчанию использует общепринятые надёжные практики. Но полезно явно спросить: «Пароли пользователей точно хранятся хешированными, а не в открытом виде?» — простая проверка, которая не помешает.

Шаг 3. Структура данных

Прежде чем создавать заявки клиентов, полезно попросить Claude Code показать, как будут устроены данные:

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

какие поля будут у пользователя, у клиента мастерской

и у заявки на ремонт

Ответ, скорее всего, будет выглядеть примерно так (мы приводим упрощённый пример, чтобы показать сам принцип):

Таблица "Пользователи": id, имя, email, пароль (хеш), роль

Таблица "Клиенты": id, имя, телефон, дата первого обращения

Таблица "Заявки": id, клиент_id, мастер_id, описание проблемы,

статус, дата создания, дата завершения

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

Шаг 4. Реализация авторизации

Реализуй регистрацию и вход по описанной структуре. После

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

приходилось вводить пароль заново при каждом переходе между

страницами. Добавь также кнопку "Выйти"

Шаг 5. Разграничение доступа

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

Убедись, что страница со списком всех заявок доступна только

администратору. Мастер при попытке напрямую открыть эту

страницу должен видеть сообщение "Доступ запрещён" и

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

ВНИМАНИЕ: Разграничение доступа — одна из тех областей, где стоит проявлять особую тщательность при проверке (вспоминая материал главы 18 первой книги о том, чему стоит доверять безоговорочно, а что перепроверять). Обязательно протестируйте сценарий «что если мастер попробует напрямую открыть адрес страницы администратора, введя его в браузере вручную» — а не только «не видна ли ссылка на эту страницу в интерфейсе». Скрытая, но фактически доступная страница — распространённая и серьёзная уязвимость.

Шаг 6. Восстановление пароля и другие практические мелочи

Реальная система авторизации обычно требует ещё нескольких вещей, о которых легко забыть на этапе первоначального планирования:

Добавь функцию "Забыли пароль?" — отправку ссылки для

сброса пароля на email пользователя

Добавь ограничение: после 5 неудачных попыток входа подряд

временно блокировать возможность входа для этого email на

15 минут, чтобы защититься от подбора пароля

Последний пример — практика, защищающая от так называемого перебора (brute force) — автоматизированных попыток угадать пароль путём быстрого перебора множества вариантов подряд.

Небольшое резюме главы

• Личный кабинет требует двух взаимосвязанных компонентов: базы данных для хранения информации разных пользователей и системы авторизации.

• Пароли должны храниться в захешированном, а не открытом виде — это стандартная и обязательная практика.

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

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

• Полноценная система авторизации включает такие практические детали, как восстановление пароля и защиту от подбора пароля.

В следующей главе — четвёртый и последний сквозной проект книги: автоматизация процессов небольшого бизнеса от заявки до отчёта.

От разрозненных задач — к цельному процессу

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

Сценарий: от заявки клиента до ежемесячного отчёта

Продолжим развивать проект «Учёт клиента» из прошлой главы и построим вокруг него полноценный процесс: клиент оставляет заявку → заявка автоматически распределяется мастеру → по завершении работы формируется запись для бухгалтерии → в конце месяца автоматически собирается отчёт по всем заявкам.

Шаг 1. Автоматическое распределение заявок

Когда поступает новая заявка без указанного мастера,

автоматически назначай её тому мастеру, у которого сейчас

меньше всего активных (незавершённых) заявок. Если у

нескольких мастеров одинаковое количество — выбирай того,

кто дольше не получал новую заявку

Обратите внимание, насколько эта задача отличается от простого CRUD-интерфейса (создание, чтение, обновление, удаление записей), которым мы занимались в предыдущей главе, — здесь появляется настоящая бизнес-логика, отражающая реальное правило распределения нагрузки в мастерской. Именно такие правила стоит формулировать предельно точно, поскольку неоднозначность здесь напрямую ведёт к неправильному, но незаметному на первый взгляд поведению системы.

Шаг 2. Уведомления на ключевых этапах

Добавь уведомления:

1. Когда заявка назначена мастеру — отправить email мастеру

с описанием заявки

2. Когда мастер отмечает заявку выполненной — отправить email

клиенту с уведомлением, что ремонт завершён

3. Если заявка находится в статусе "в работе" дольше 3 дней

без изменений — отправить email администратору с

напоминанием проверить эту заявку

Третий пункт — хороший пример автоматизации, которая не просто реагирует на действие пользователя, а сама отслеживает время и инициирует действие при определённых условиях. Такая логика обычно реализуется через периодическую фоновую проверку (например, раз в час) — стоит явно спросить у Claude Code, как именно организована эта проверка в вашем случае, чтобы понимать общий принцип.

Шаг 3. Автоматическое формирование отчёта

Добавь автоматическое формирование ежемесячного отчёта в

формате Excel: первого числа каждого месяца собирать все

заявки за прошедший месяц со статусами, суммами и мастерами,

и отправлять готовый файл на email администратора

РАЗБОР КЕЙСА. При реализации подобной задачи полезно сразу же попросить возможность запустить формирование отчёта вручную, не дожидаясь начала следующего месяца: «Добавь также кнопку в административной панели “Сформировать отчёт за текущий период сейчас”, чтобы я мог проверить, что всё работает правильно, не дожидаясь календарной даты». Это общий, крайне полезный приём при работе с любой логикой, привязанной к дате или времени, — тестирование по «настоящему» календарю занимает недели, тестирование по требованию — секунды.

Шаг 4. Взгляд на процесс целиком

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

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

момента, когда информация о ней попадает в месячный отчёт —

по шагам, включая все автоматические уведомления

Такой запрос выполняет ту же функцию, что и просьба «объяснить, что было сделано» из первой книги (глава 11), но применительно уже не к отдельному изменению, а ко всему выстроенному процессу целиком — это хороший способ убедиться, что общая картина в голове совпадает с тем, что реально реализовано.

Пределы автоматизации: когда стоит остановиться

Соблазн автоматизировать абсолютно всё довольно велик, но не каждая задача выигрывает от полной автоматизации. Если какой-то шаг процесса требует человеческого суждения, редко повторяется или его последствия при ошибке серьёзны (например, окончательное решение об увольнении сотрудника или крупный финансовый платёж), разумнее оставить финальное решение за человеком, автоматизировав лишь подготовку информации для этого решения.

СОВЕТ: Хороший ориентир — автоматизировать сбор информации и рутинные, часто повторяющиеся действия с понятными и предсказуемыми правилами, но оставлять точку принятия решения за человеком там, где цена ошибки высока или правило сложно сформулировать однозначно.

Небольшое резюме главы

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

• Бизнес-правила (например, порядок распределения заявок) стоит формулировать предельно точно, поскольку неоднозначность приводит к незаметным, но реальным ошибкам поведения.

• Для логики, привязанной к дате или времени, полезно сразу предусмотреть возможность запуска вручную для тестирования.

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

Мы завершили часть, посвящённую сквозным реальным проектам. В следующей части книги переходим к профессиональным практикам — начиная с тестирования.

Глава 8. Тестирование: как убедиться, что всё работает, не проверяя вручную