Многие руководители на старте проекта говорят: сделаем сайт и админку вместе — так проще.
Звучит разумно, но на практике чаще всего возникают три ситуации: сайт уже запущен, а админка всё ещё дорабатывается; изменилось поле в админке — и все страницы сайта приходится переделывать; обе части делают разные люди, API не сходятся, и в итоге все ждут друг друга.
Проблема не в том, что «делаем вместе», а в том, что нет порядка планирования. Ниже разберём этот вопрос на основе реального опыта проектов.
Сначала определите данные админки, потом страницы сайта
Сайт — это слой отображения, админ-панель — слой данных. Если порядок обратный, переделки почти неизбежны.
Конкретный пример: компания по производству промышленного оборудования хочет обновить сайт и одновременно сделать админку, чтобы менеджеры по продажам сами обновляли параметры продукции, кейсы и новости. Если сначала нарисовать главную страницу сайта, а потом думать, как заполнять админку, типичный результат — поля в админке спроектированы наугад: например, «особенности продукта» — это одно поле с rich-текстом, а на сайте нужно вывести три пункта в ряд. В итоге редактор верстает вручную, и через полгода контент превращается в хаос.
Более надёжный подход — сначала составить модель контента: какие поля есть у продукта, с каким продуктом связан кейс, нужна ли категоризация новостей, нужны ли изображения в нескольких размерах. Когда поля определены, структура страниц сайта складывается сама собой.
Типичная ошибка: не приравнивайте поля админки к полям базы данных. Названия полей для редактора должны быть понятными, технические поля храните отдельно — иначе оператор заполнит форму пару раз и бросит это дело.
Сначала API, не ждите, пока обе части будут готовы, для интеграции
При параллельной разработке сайта и админки больше всего времени теряется на интеграции.
Рекомендуется зафиксировать документацию API уже на первой неделе разработки, пусть даже в виде письменной договорённости: что возвращает список, как называются параметры пагинации, адрес изображения — относительный путь или полный URL. Фронтенд может сначала прогнать страницы на тестовых данных, а бэкенд выдаёт результат по той же договорённости.
Есть деталь, которую легко упустить: сайт и мини-программа часто используют один набор API. Если компания в дальнейшем планирует мини-программу для записи на приём, в дизайне API админки нужно заранее учесть урезание полей для мобильных устройств — не возвращайте все большие поля с PC-версии. С разработкой App то же самое: добавляйте версионирование API с самого начала, и дальнейшие изменения будут намного проще.
Типичная ошибка: не смешивайте китайские и английские названия полей API и не пихайте в один эндпоинт три разных назначения. Лучше два лишних API, чем один универсальный.
Права доступа и процесс публикации нужно продумать уже в первой версии
В админ-панели не бывает только одной роли администратора.
В реальных проектах обычно есть как минимум: супер-администратор, контент-редактор, менеджер по продажам или руководитель региона. Если в первой версии сделать только один аккаунт, то при добавлении прав придётся менять структуру таблиц — это гораздо дороже, чем спроектировать сразу.
С процессом публикации то же самое. Нужна ли модерация контента перед публикацией на сайте? Нужно ли сохранять черновики новостей? Это не функции «на потом», а вещи, влияющие на структуру таблиц.
Практичный подход: добавить в таблицу контента поле статуса (черновик, на модерации, опубликовано), а в таблицу ролей — область действий. В первой версии можно открыть только две роли, но структуру заложить заранее.
Типичная ошибка: не вшивайте права доступа в страницы. Скрытая кнопка на фронтенде — это не контроль доступа, проверка обязательна на уровне API. Для корпоративного сайта, где есть заявки и данные клиентов, это особенно важно.
Разделите график запуска на два этапа, не привязывайте всё к одному релизу
Делать сайт и админку вместе — не значит запускать их одновременно.
Более надёжный график: сначала запускается админка, отлаживается ввод контента; затем публикуется сайт, заполненный реальными данными. Так при первом показе сайта контент уже полный, а не добавляется после запуска.
Если времени мало, можно сначала выпустить статическую версию сайта, параллельно разрабатывать админку и на второй неделе переключить источник данных. Условие — структура страниц уже определена по модели контента, и при переключении не нужно менять вёрстку.
Типичная ошибка: оставьте время на тестирование безопасности перед запуском. Корпоративный сайт включает отправку форм и вход в админку — нужно проверить типичные уязвимости: инъекции, обход прав, слабые пароли. Этот объём работ отдельный от самой разработки сайта, не упустите его при планировании.
В каких случаях стоит обратиться в MIC Studio
Если в команде есть стабильные фронтенд- и бэкенд-разработчики, планируйте по описанному выше порядку самостоятельно — внешняя помощь не нужна.
Но в следующих случаях внешняя команда сэкономит время: во-первых, обновление сайта и админка стартуют одновременно, а внутри только один человек на связи — нужен кто-то, кто свяжет требования и график; во-вторых, к существующей системе нужно добавить разработку мини-программы или App, API нужно переиспользовать — нужен человек, который сначала разберёт структуру данных; в-третьих, перед запуском нужно провести тестирование безопасности сайта или обратный инжиниринг, а внутри нет соответствующего опыта.
MIC Studio, берясь за такие проекты, обычно сначала проводит этап анализа требований и составления списка полей, а затем переходит к планированию разработки сайта — чтобы не переделывать по ходу. Мы не обещаем позиций в рейтингах и не даём преувеличенных обещаний — важнее чётко обозначить границы и сроки.
Три выполнимых совета
1. На первой неделе проекта сначала составьте модель контента и список ролей, потом рисуйте страницы. Пока поля не определены, не спешите с дизайн-макетами.
2. Документация API и тестовые данные для фронтенда стартуют одновременно — время на интеграцию можно сократить более чем вдвое.
3. Разделите запуск: сначала админка, затем сайт, между ними оставьте время на тестирование безопасности и наполнение контентом.
Выполните эти три пункта — и совместная разработка сайта и админ-панели перестанет быть риском и станет способом сэкономить.