Доработка модулей Битрикс, Аспро и Marketplace без потери обновляемости

Доработка модулей на 1С-Битрикс — это изменение поведения готовых решений под задачи вашего бизнеса без переписывания их с нуля. На большинстве проектов сайт собран из трёх слоёв: ядро самого Битрикса, готовое решение вроде Аспро и набор модулей из Маркетплейса. Каждый из этих слоёв регулярно обновляется производителем, и любая правка, сделанная напрямую в их файлах, при ближайшем обновлении затирается. Наша задача — встроить нужную логику так, чтобы она пережила обновления и не превратила сайт в неподдерживаемый набор хаков.

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

Что входит в доработку модулей

Под доработкой модулей мы понимаем широкий спектр задач — от мелкой кастомизации готового решения Аспро до написания собственного модуля с админкой и API. Чаще всего речь идёт о доработке логики оформления заказа, каталога и фильтров, личного кабинета, интеграций и обмена данными. Иногда нужно изменить уже купленный в Маркетплейсе модуль, который почти подходит, но не закрывает один-два сценария. Иногда — наоборот, заменить громоздкий сторонний модуль собственным компонентом, который делает ровно то, что нужно, и не тянет лишнего.

Основные направления работ:

• кастомизация решений Аспро — шаблонов, компонентов и настроек без правок самого решения;
• доработка модулей из Маркетплейса под недостающие сценарии и интеграции;
• разработка собственных модулей и компонентов под уникальную логику проекта;
• безопасные правки поведения ядра через события и обработчики, а не через хаки;
• обеспечение совместимости доработок при обновлениях Битрикса, Аспро и модулей;
• рефакторинг накопленных хаков и приведение проекта к обновляемому состоянию.

Кому нужна доработка модулей на Битрикс

Услуга нужна тем, у кого сайт работает на готовом решении или наборе модулей, но какие-то сценарии решение закрывает не полностью. Это магазины и B2B-порталы на Аспро, которым нужно изменить логику корзины, цен или кабинета. Это проекты, где модуль из Маркетплейса почти подходит, но не хватает одной интеграции или поля. Это компании, которые однажды получили сайт с прямыми правками решения и теперь боятся нажать кнопку обновления, потому что после неё всё ломается.

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

Как мы делаем доработки безопасными

Главный принцип — обновляемость не приносится в жертву скорости. Перед началом мы смотрим, как устроено решение и модуль, какие точки расширения они предоставляют, и выбираем способ доработки, который переживёт обновление. Логику поведения мы выносим в обработчики событий, кастомные шаблоны компонентов держим в собственном пространстве, а сложную функциональность оформляем отдельным модулем с понятной структурой. Каждую доработку мы документируем, чтобы её можно было сопровождать и развивать без нас.

Перед сдачей мы проверяем, что доработка не конфликтует с обновлениями: прогоняем обновление решения и модулей на тестовой копии и убеждаемся, что кастомизация остаётся на месте. Так вы получаете не разовую заплатку, а изменение, которое живёт вместе с проектом. Результат доработки модулей Битрикс, Аспро и Marketplace — сайт, который делает именно то, что нужно бизнесу, и при этом продолжает обновляться, оставаясь безопасным и поддерживаемым.

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

Когда готовое решение почти закрывает задачу, но не дотягивает в одном-двух сценариях, перед командой всегда стоит выбор: доработать его правильно, через штатные точки расширения, или быстро — прямой правкой файлов решения. Второй путь кажется дешевле и быстрее: открыл нужный файл, поменял пару строк, готово. Но именно так проекты на 1С-Битрикс и Аспро превращаются в неподдерживаемый набор хаков, который ломается при каждом обновлении. Ниже мы разбираем, чем эти подходы отличаются на длинной дистанции, какие проблемы решает безопасная доработка и как мы выстраиваем работу, чтобы кастомизация жила вместе с проектом.

Почему прямые правки решения — это технический долг

Решение вроде Аспро и модули из Маркетплейса регулярно обновляются: вендор выпускает исправления безопасности, новые возможности и совместимость с новыми версиями Битрикса. Когда вы правите файлы решения напрямую, обновление перезаписывает их — и ваша доработка исчезает. Дальше события развиваются по одному из двух плохих сценариев. Либо вы перестаёте обновляться, чтобы не потерять правки, — и копите дыры в безопасности и несовместимость. Либо обновляетесь и каждый раз заново вручную восстанавливаете изменения, теряя на этом часы разработчика и рискуя что-нибудь упустить.

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

Что значит доработка без потери обновляемости

Платформа 1С-Битрикс изначально спроектирована расширяемой. У неё есть события и обработчики, через которые можно вмешиваться в поведение ядра и модулей, не трогая их код. Компоненты можно переопределять, скопировав шаблон в собственный шаблон сайта, — оригинал при этом остаётся нетронутым. Классы можно наследовать и расширять. А сложную уникальную логику можно оформить отдельным собственным модулем, который живёт рядом с решением, но не зависит от его внутренностей. Все эти механизмы переживают обновления, потому что не вмешиваются в обновляемые файлы.

Когда мы дорабатываем решение Аспро, мы не открываем его файлы на редактирование. Нужно изменить вывод каталога или карточки — переопределяем шаблон компонента в своём шаблоне. Нужно изменить логику цены, заказа или скидки — вешаем обработчик на соответствующее событие. Нужна функциональность, которой в решении нет вовсе, — пишем собственный модуль или компонент. Решение остаётся в исходном виде, продолжает обновляться и получать поддержку вендора, а ваша кастомизация спокойно живёт в обёртке поверх него. Эту же логику мы применяем к модулям Маркетплейса и к ядру самого Битрикса.

Кастомизация Аспро без потери поддержки

Аспро — это мощное готовое решение, которое закрывает большую часть задач интернет-магазина или корпоративного сайта из коробки. Но почти на каждом проекте находится что-то, что хочется изменить: логика корзины, отображение цен для разных групп, поведение фильтров, шаблон личного кабинета, интеграция с внешним сервисом. Соблазн поправить это прямо в решении велик, потому что так быстрее. Мы идём другим путём: переопределяем нужные компоненты в собственном шаблоне и выносим логику в обработчики событий. В результате вы получаете нужное поведение, но решение остаётся обновляемым и поддерживаемым вендором. Если вам нужна более глубокая работа с решением, это направление мы развиваем в услуге внедрения и доработки Аспро, где собираем и кастомизируем решение под проект целиком.

Отдельно стоит сказать про шаблоны. Любые изменения вёрстки и вывода данных мы держим в своём шаблоне сайта, а не в шаблоне решения. Так при обновлении Аспро ваши визуальные доработки не затираются, а решение спокойно подтягивает новые версии своих компонентов. Это базовая гигиена, которая экономит десятки часов на каждом обновлении и снимает страх перед апдейтом.

Доработка модулей Маркетплейса

Модули из Маркетплейса 1С-Битрикс часто закрывают задачу на девяносто процентов, но именно последние десять процентов и оказываются важными для бизнеса. Не хватает одной интеграции, одного поля, одного сценария. Прямая правка исходников модуля здесь так же опасна, как и правка решения: автор модуля выпустит обновление, и ваши изменения исчезнут. Мы сначала смотрим, какие точки расширения предоставляет сам модуль — события, настройки, хуки. Очень часто нужный сценарий можно дорастить через них, не касаясь чужого кода.

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

Когда нужен собственный модуль

Собственный модуль оправдан, когда логика проекта уникальна и не закрывается ни решением, ни готовыми модулями. Это могут быть особые правила ценообразования для дилеров, нестандартный обмен данными с учётной системой, своя механика лояльности или специфический бизнес-процесс. Вместо того чтобы рассыпать эту логику вставками по чужому коду, мы собираем её в один модуль с понятной структурой, настройками в админке и документацией. Такой модуль легко сопровождать, тестировать и развивать, и он не зависит от обновлений сторонних компонентов.

Собственный модуль также решает проблему прозрачности. Когда логика разбросана по правкам в разных файлах, разобраться в ней может только тот, кто их делал. Когда она собрана в модуль, любой разработчик видит, где что лежит и как это работает. Это особенно важно, если проект сопровождает несколько команд или если вы планируете передавать его другому подрядчику. Мы всегда передаём исходники и документацию, чтобы доработка не привязывала вас к нам.

Рефакторинг накопленных хаков

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

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

Как мы проверяем совместимость

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

Гарантии и прозрачность

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

Возражения, которые мы слышим чаще всего

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

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

«Боимся, что после доработки нас привяжут к подрядчику». Это обоснованный страх, потому что непрозрачный код действительно привязывает. Мы работаем наоборот: пишем понятный код, документируем доработки и передаём исходники. Любая другая команда сможет разобраться и продолжить, а мы остаёмся с вами по желанию, а не по необходимости.

С чего начать

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

И ещё одно соображение напоследок. Сайт на 1С-Битрикс — это живой организм, который меняется вместе с бизнесом: добавляются товары и услуги, появляются новые сценарии, растут требования к скорости и безопасности. Доработки накапливаются, и от того, как они сделаны, зависит, будет ли проект с годами становиться удобнее в развитии или, наоборот, превратится в трудноподдерживаемый монолит. Мы выбираем первый путь и закладываем его в каждую доработку: понятная структура, обёртки вместо хаков, документация и переданные исходники. Так каждое следующее изменение опирается на аккуратный фундамент, а не на россыпь правок, и стоимость развития проекта со временем снижается, а не растёт. Именно в этом и состоит разница между доработкой правильно и доработкой быстро.