Разработка кастомного модуля «Каталог квартир» на Bitrix с административной панелью и публичной фильтрацией
Клиент: Крупная строительная компания (девелопер).
Бизнес-задача:
Клиенту требовалось реализовать на сайте функциональный модуль «Квартиры в продаже», который позволил бы выводить список квартир с фильтрацией, а также предоставить сотрудникам удобную админпанель для управления данными.
Исходные требования (ТЗ):
Основные проблемы в процессе приёмки:
В ходе тестирования было выявлено более 15 критических и неприятных багов, а также несоответствий ожиданиям бизнес-пользователя. Модуль не принимался заказчиком, так как работа админки и логика данных были нестабильны.
3. Процесс решения (Ход работ)
Этап 1. Уточнение требований
В самом начале команда зафиксировала два принципиальных вопроса, которые не были явно прописаны в ТЗ:
1. Модуль vs. код в сайте: заказчик подтвердил, что требуется именно упакованное решение в виде модуля Bitrix (с установкой через /bitrix/admin/partner_modules.php).
2. ORM и объекты: уточнено, что использование ORM Bitrix допустимо (даже если она возвращает массивы), а требование «использование объектов» трактуется как создание классов-сущностей для бизнес-логики.
Этап 2. Разработка и первая упаковка в модуль
Этап 3. Фаза тестирования и массового исправления багов (ключевой этап)
В ленте задачи зафиксировано более 20 замечаний, которые были сгруппированы и последовательно исправлены. Ниже — наиболее показательные:
Критические логические ошибки:
UX/UI-проблемы админки:
Проблемы с доступом и архитектурой:
Этап 4. Применение паттерна PRG и финальные доработки
4. Результат
Что получил бизнес:
Бизнес-выгода (логический вывод):
Сотрудники компании перестали тратить время на ручное исправление ошибок в данных («0» вместо пустого поля, дубли квартир). Менеджеры получили понятный интерфейс, а технический отдел — готовое модульное решение, которое не конфликтует с обновлениями ядра Bitrix.
5. Выводы
1. Даже детальное ТЗ не отменяет фазы активного тестирования. Большинство багов были связаны не с архитектурой, а с мелкими UX-сценариями (F5, пустое поле, снятие активности).
2. При разработке админок на Bitrix обязательны:
3. Упаковка в модуль с самого начала (а не в конце) экономит время — команда не переписывала пути, а сразу тестировала установку/удаление.
4. Чек-лист — живой инструмент. В процессе было добавлено несколько новых пунктов («список квартир для дома», «скрыть ссылку перехода для пустого дома»), что повысило качество финального продукта.
Клиент: Крупная строительная компания (девелопер).
Бизнес-задача:
Клиенту требовалось реализовать на сайте функциональный модуль «Квартиры в продаже», который позволил бы выводить список квартир с фильтрацией, а также предоставить сотрудникам удобную админпанель для управления данными.
Исходные требования (ТЗ):
- Публичная часть: вывод списка квартир в продаже, фильтрация по дому и по наличию скидки (без перезагрузки страницы).
- Административная часть: просмотр, добавление, редактирование квартир и связанных с ними домов.
- Технические ограничения:
- Не использовать инфоблоки и HighLoad-блоки Bitrix.
- Использовать ORM Bitrix.
- Рассчитать архитектуру на масштаб: до 100 000 квартир и 1 000 домов.
- Решение должно быть оформлено как полноценный устанавливаемый модуль, а не просто код в пространстве сайта.
Основные проблемы в процессе приёмки:
В ходе тестирования было выявлено более 15 критических и неприятных багов, а также несоответствий ожиданиям бизнес-пользователя. Модуль не принимался заказчиком, так как работа админки и логика данных были нестабильны.
3. Процесс решения (Ход работ)
Этап 1. Уточнение требований
В самом начале команда зафиксировала два принципиальных вопроса, которые не были явно прописаны в ТЗ:
1. Модуль vs. код в сайте: заказчик подтвердил, что требуется именно упакованное решение в виде модуля Bitrix (с установкой через /bitrix/admin/partner_modules.php).
2. ORM и объекты: уточнено, что использование ORM Bitrix допустимо (даже если она возвращает массивы), а требование «использование объектов» трактуется как создание классов-сущностей для бизнес-логики.
Этап 2. Разработка и первая упаковка в модуль
- Команда спроектировала таблицы БД через ORM Bitrix.
- Административный интерфейс был реализован с учётом современных рекомендаций Bitrix (по аналогии со страницами rubric_admin.php).
- На середине разработки код был упакован в модуль modulecode.apartments. Это потребовало пересборки окружения — при смене веток Git и переустановке модуля часть файлов перезаписывалась.
Этап 3. Фаза тестирования и массового исправления багов (ключевой этап)
В ленте задачи зафиксировано более 20 замечаний, которые были сгруппированы и последовательно исправлены. Ниже — наиболее показательные:
Критические логические ошибки:
- В одном доме можно было создать две квартиры с одинаковым номером — нарушение уникальности.
- При сохранении пустого числового поля в БД записывался 0 вместо NULL (некорректная бизнес-логика).
- При снятии флага «Активность» значение не сохранялось.
- При удалении картинки и немедленной загрузке новой, после нажатия «Применить» изображение не сохранялось.
- Демо-данные заполнялись некорректно: стоимость со скидкой равнялась стоимости без скидки.
UX/UI-проблемы админки:
- После нажатия «Сохранить» пользователь оставался на странице редактирования, а должен был возвращаться в список.
- Кнопка «Отменить» не работала.
- Активный пункт меню не подсвечивался.
- Русские названия полей отсутствовали (были технические английские).
- Для пустого дома ссылка «Перейти» вела в никуда — её скрыли.
- В списке элементов работала фильтрация только по активности, а не по другим свойствам; сортировка не работала.
- После сохранения формы и обновления страницы (F5) браузер требовал повторной отправки POST-данных — нарушение паттерна Post/Redirect/Get.
Проблемы с доступом и архитектурой:
- Файлы админки были доступны для прямого захода вне логики модуля (без авторизации в админке).
- В карточке редактирования квартиры отсутствовала возможность быстрого редактирования связанного дома.
Этап 4. Применение паттерна PRG и финальные доработки
- Для исправления ошибки с повторной отправкой формы команда внедрила паттерн Post/Redirect/Get.
- Настроена кликабельная ссылка на дом как в списке квартир, так и при создании новой квартиры.
- Добавлена возможность удаления элемента не только из списка, но и из карточки редактирования (было выполнено в порядке улучшения).
- Улучшена работа фильтра «Дом» — теперь его скрытие/показ не требовало обновления страницы.
4. Результат
Что получил бизнес:
- ✅ Рабочий модуль «Квартиры», который можно устанавливать на любой проект на Bitrix без доработок.
- ✅ Админка с русским интерфейсом, предсказуемым поведением кнопок и корректной валидацией (защита от дублей номеров в пределах дома, корректная обработка пустых значений).
- ✅ Публичный фильтр по дому и скидке без перезагрузки страницы.
- ✅ Защиту прямого доступа к служебным файлам админки.
- ✅ Масштабируемость — архитектура с использованием ORM и учётом 100 000+ квартир.
Бизнес-выгода (логический вывод):
Сотрудники компании перестали тратить время на ручное исправление ошибок в данных («0» вместо пустого поля, дубли квартир). Менеджеры получили понятный интерфейс, а технический отдел — готовое модульное решение, которое не конфликтует с обновлениями ядра Bitrix.
5. Выводы
1. Даже детальное ТЗ не отменяет фазы активного тестирования. Большинство багов были связаны не с архитектурой, а с мелкими UX-сценариями (F5, пустое поле, снятие активности).
2. При разработке админок на Bitrix обязательны:
- Паттерн Post/Redirect/Get.
- Правильная обработка NULL вместо приведения к 0.
- Проверка уникальности на уровне бизнес-логики, а не только БД.
3. Упаковка в модуль с самого начала (а не в конце) экономит время — команда не переписывала пути, а сразу тестировала установку/удаление.
4. Чек-лист — живой инструмент. В процессе было добавлено несколько новых пунктов («список квартир для дома», «скрыть ссылку перехода для пустого дома»), что повысило качество финального продукта.
управление модулем в админ панели
разработка с использованием GIT