Проектирую и разрабатываю функциональность на 1С-Битрикс так, чтобы сайт можно было поддерживать после запуска: через инфоблоки, компоненты, шаблоны, события, свойства, кеш и понятную структуру данных.
Эта услуга подходит для живых проектов, где нельзя просто «быстро поправить файл на продакшене». Важно сохранить заявки, каталог, SEO-страницы, интеграции и привычную работу редакторов в административной части.
Обычно ко мне приходят не за установкой готового модуля, а за аккуратной доработкой существующего сайта. Например, нужно добавить новый раздел, изменить каталог, собрать личный кабинет, доработать карточку товара, подключить форму, изменить логику фильтра или связать несколько сценариев между собой.
В Битриксе почти любая задача затрагивает несколько слоев: публичную верстку, компонент, инфоблок, свойства, кеш, права доступа и иногда почтовые события или внешние API. Поэтому я заранее разбираю не только «что должно появиться на экране», но и где это будет храниться, кто сможет это редактировать и какие соседние сценарии зависят от изменения.
Перед изменениями смотрю текущие шаблоны, компоненты, инфоблоки, свойства, обработчики событий и зависимые разделы. Это помогает понять, где лучше развивать существующую логику, а где безопаснее вынести функциональность в отдельный компонент, модуль или служебный класс.
Для Битрикса особенно важны границы доработки. Одна небольшая правка в шаблоне может затронуть список, детальную страницу, фильтр, кеш, мета-теги или выгрузку. Поэтому в оценке я отдельно смотрю, есть ли кастомные компоненты, старые обработчики, правки ядра, нестандартные свойства и внешние интеграции.
Если проект давно не обслуживали, перед крупной разработкой полезно сделать аудит сайта на 1С-Битрикс. Если задачи идут регулярно, удобнее оформить поддержку сайта на Битрикс, чтобы не начинать каждый раз с долгого разбора проекта.
Для первичной оценки достаточно ссылки на сайт, описания задачи, примера нужного поведения и списка сценариев, которые нельзя сломать. Если есть макет, тестовая копия, Git, список предыдущих доработок или доступ к админке, оценка получается точнее.
Для задач с каталогом отдельно важны свойства товаров, фильтры, торговые предложения, правила сортировки и SEO-поля. Для форм — поля, почтовые события, CRM, защита от спама и место, где заявка должна сохраняться.
Разработка на 1С-Битрикс нужна, когда требуется новая логика или заметное изменение существующего сценария: другой способ оформления заказа, новый тип страниц, управляемый блок, интеграция, личный кабинет, переработка каталога или сложная форма. Это больше, чем разовая правка, потому что затрагивает архитектуру сайта и будущую поддержку.
Исправление ошибок подходит, если есть конкретный сломанный сценарий. Поддержка сайта нужна для регулярных мелких задач и контроля состояния. А разработка начинается там, где нужно спроектировать, реализовать и проверить новую функциональность так, чтобы она не конфликтовала с текущими компонентами, кешем, SEO и интеграциями.
Для каждой доработки заранее фиксирую проверяемый результат: какие страницы меняются, какие роли пользователей участвуют, какие письма, статусы, события аналитики или записи в инфоблоках должны появиться после действия. Это помогает принимать работу не по ощущению, а по понятному сценарию.
В проекте Alean Collection была подготовлена логика добавления отелей и связанных страниц с индивидуальными темами оформления. На сайте Андрея Курпатова повторяемые блоки и контентные разделы сделаны управляемыми, а формы подключены к общей структуре сайта. Это примеры задач, где нужно проектировать данные и шаблоны, а не ограничиваться одной правкой файла. О границе между доработкой и переделкой рассказываю в отдельном разборе, а подготовиться к передаче проекта поможет чек-лист выбора разработчика.
Да, если текущая структура позволяет безопасно внести изменения. Перед началом я смотрю, где находится нужная логика и какие разделы она затрагивает.
В Битриксе одна и та же задача может быть простой правкой шаблона или изменением компонента, свойств, событий, кеша и интеграций. Точная оценка появляется после просмотра проекта.
Лучше начать с диагностики: проверить компоненты, шаблоны, кеш, логи и места кастомного кода. Это снижает риск повторных поломок и помогает планировать доработки по приоритету.
Оценка после постановки задачи, макета или доступа к текущему проекту.
Оставьте контакты, и я свяжусь с вами.
MAX
