Разработка модуля управления квартирами («Квартиры в продаже») для сайта застройщика
Разработка кастомного модуля «Каталог квартир» на Bitrix с административной панелью и публичной фильтрацией
Клиент: Крупная строительная компания (девелопер).
Бизнес-задача:
Клиенту требовалось реализовать на сайте функциональный модуль «Квартиры в продаже», который позволил бы выводить список квартир с фильтрацией, а также предоставить сотрудникам удобную админпанель для управления данными.
Исходные требования (ТЗ):
Публичная часть: вывод списка квартир в продаже, фильтрация по дому и по наличию скидки (без перезагрузки страницы).
Административная часть: просмотр, добавление, редактирование квартир и связанных с ними домов.
Технические ограничения:
Не использовать инфоблоки и 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. Чек-лист — живой инструмент. В процессе было добавлено несколько новых пунктов («список квартир для дома», «скрыть ссылку перехода для пустого дома»), что повысило качество финального продукта.