Доработка интернет-магазина на Laravel: как оценить задачу и выпустить изменение

В магазине на Laravel нужно добавить доставку, поменять правила скидок или исправить зависающие заказы. Разработчик предлагает «сначала разобраться в проекте», но сколько займёт разбор и что вы получите после него, непонятно. Ещё хуже, когда небольшая доработка превращается в предложение переписать магазин, который продолжает продавать.

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

Отделите аварию от задачи развития

«Не проходит оплата» и «хотим ещё один способ оплаты» требуют разного порядка работы. При аварии сначала выясняют, что происходит с уже созданными заказами и деньгами. При развитии сначала описывают новое поведение и оценивают связанные изменения. Обновление версии Laravel — третья задача: оно может быть необходимо для сопровождения, но само по себе не добавляет нужную покупателю функцию.

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

Попросите ограниченный разбор с конкретным выходом

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

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

Например, сообщение «тормозит Laravel» ничего не объясняет. Проверяемая формулировка звучит иначе: «При открытии заказов менеджер ждёт внешний сервис доставки; при его задержке список тоже не отвечает». Из неё появляется предмет обсуждения: можно ли отделить получение списка от внешнего запроса, как показывать устаревшее состояние и когда повторять обращение к сервису.

Соберите паспорт работающего магазина

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

Отдельно перечислите оплаты, доставку, 1С, CRM, почту, хранилище файлов и мониторинг. У каждого соединения должны быть ответственный, назначение и тестовый режим, если он доступен. Пароли, рабочие ключи и выгрузки покупателей передаются по согласованному защищённому каналу с необходимым уровнем доступа. Для первой оценки часто достаточно обезличенных примеров.

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

Проследите одну операцию от действия до результата

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

На официальном примере Laravel Telescope видны отдельный запрос, его путь, ответ и длительность. В реальном разборе аналогичные записи помогают восстановить последовательность событий. Показанный запрос к тестовому приложению не демонстрирует платёжную интеграцию: инструмент только предоставляет данные для диагностики.

Для заказчика важен вывод по операции: деньги подтверждены провайдером или нет, какой заказ им соответствует, что произошло при обработке и как безопасно восстановить согласованное состояние. Если уведомление повторится, система не должна создавать второй заказ или повторно выполнять уже завершённое действие. Конкретный способ защиты зависит от используемого платёжного API и реализации магазина.

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

Опишите изменение на одном сложном заказе

Возьмём добавление частичного возврата. Фраза «дать менеджеру возможность вернуть одну позицию» скрывает несколько вопросов. Как распределяется скидка? Возвращается ли доставка? Что происходит с остатком и документом в 1С? Можно ли нажать кнопку повторно? У какой роли есть право на действие?

Учебный заказ: два товара после распределённой скидки стоят 5 400 и 3 600 ₽, доставка — 500 ₽. Покупатель заплатил 9 500 ₽. Если согласованный сценарий возвращает только второй товар без доставки, сумма возврата — 3 600 ₽, а оставшаяся оплаченная часть — 5 900 ₽. Если правила другие, результат нужно пересчитать до разработки. Это пример проверки, а не универсальное правило возврата.

На экране Bagisto из официальной документации отдельно показаны количество, доставка и корректировки суммы. Полезно обсуждать именно состав операции. Запись о возврате в магазине и фактический возврат у платёжного провайдера — разные результаты; их связь нужно проверить для выбранного способа оплаты.

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

Проверьте не только новую кнопку

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

В публичном репозитории Laravel можно посмотреть, как автоматические проверки привязаны к определённой версии кода. На скриншоте показан успешный запуск тестов самого фреймворка, а не магазина CAPS. Он иллюстрирует формат доказательства: какой код проверяли, какие задания выполнили и чем закончился запуск.

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

Согласуйте выпуск и откат до изменения базы

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

Для значимых изменений команда может применять поэтапную совместимость: сначала добавить новые данные без удаления старых, затем перевести приложение на новый способ работы и только после проверки убрать устаревшую структуру. Подход выбирают под проект; его нельзя заменить общим обещанием «всё откатим из бэкапа».

Официальная документация Laravel отдельно требует учитывать долгоживущие процессы при выпуске: обработчики очередей могут продолжать выполнять прежний код, пока их корректно не перезапустят. Конкретные команды зависят от версии и инфраструктуры. Заказчику нужен подтверждённый результат: новая версия работает и в браузере, и в обработке фоновых заданий.

Если после выпуска появились новые покупки, возврат всей вчерашней базы может их уничтожить. Поэтому план отката должен объяснять судьбу новых заказов, платежей и изменений в 1С. До переключения проверяют восстановление копии отдельно, а после — контрольную торговую цепочку и состояние очередей.

Сравнивайте стоимость по результатам этапов

Небольшое изменение можно оценить отдельно после разбора затронутой логики. Если неизвестных много, разумно выделить ограниченную диагностику, затем согласовать реализацию. Для почасовой работы нужны предел расходов, порядок согласования превышения и понятный отчёт: что исследовано, изменено и проверено. Фиксированная цена требует записанного объёма и исключений.

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

Что проверить на приёмке до закрытия задачи

1. Согласованный сложный заказ проходит новый сценарий с правильными суммами.
2. Обычные покупки и работа менеджера не изменились неожиданно.
3. Повтор запроса или уведомления не создаёт лишнюю торговую операцию.
4. Ошибка внешнего сервиса обнаруживается, данные сохраняются по заданным правилам.
5. Права проверены под рабочей ролью, а не только под администратором.
6. На телефоне доступны все поля, сообщения об ошибках и действия.
7. Код зафиксирован, порядок выпуска и восстановления описан.
8. После публикации проверены фоновые задания и связанная система учёта.

Скачать таблицу постановки и приёмки доработки. В ней можно записать исходные данные, правильный результат, ответственного и доказательство проверки. Вопросы о формате обмена вынесены в отдельный разбор интеграции Laravel с 1С.

С чего начать обращение в CAPS

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

CAPS берёт задачи по развитию интернет-магазинов и интеграций. Начнём с определения границ изменения и того, как проверить результат. Если доработка существующей системы решает задачу, её стоит сравнить с полной заменой до выбора дорогого маршрута. Для нового магазина состав работ раскрыт в материале о разработке на Laravel с админкой.