Мы разберем ситуацию, когда в последних релизах конфигураций 1С, особенно в профессиональных версиях, некоторые общие модули начали поставляться без исходных текстов, в виде скомпилированного байт-кода. Выясним, почему это происходит, как это влияет на работу разработчиков и пользователей, и рассмотрим основные методы взаимодействия с такими модулями. Это значимое изменение, требующее адаптации и понимания новых подходов к разработке и поддержке систем на платформе 1С:Предприятие.
Когда мы говорим о "закрытом коде" в контексте 1С, мы имеем в виду модули, которые поставляются не в виде привычных исходных текстов на встроенном языке, а в виде скомпилированного байт-кода. Это означает, что при просмотре такого модуля в конфигураторе вместо читаемого текста программы, который мы привыкли видеть и изменять, мы обнаруживаем либо пустой модуль, либо специальные метаданные, указывающие на его скомпилированный формат.
Такой модуль не содержит человекочитаемого исходного текста, что делает его прямую модификацию или даже простое чтение логики невозможным стандартными средствами. Примером такого модуля может быть ОбщийМодуль.ЕдиныйНалоговыйСчетИнтеграцияФормыПереопределяемый или ОбщийМодуль.РасчетЗарплатыДляНебольшихОрганизаций. Наличие скомпилированного байт-кода является ключевой особенностью закрытых модулей, которую мы обязательно должны учитывать в нашей работе.
Многие пользователи и разработчики задаются вопросом: является ли закрытие кода типовых модулей абсолютно новым явлением? Проанализируем исторические данные и мнения участников форума, чтобы получить полное представление о ситуации.
Практика существовала давно в базовых версиях: Мы обнаруживаем, что в базовых версиях конфигураций, например, в "1С:Бухгалтерии" (БП), модули с закрытым исходным кодом существовали уже много лет. Так, еще в 2015 году в типовой конфигурации БП 3.0.39.55 модуль СверкаДанныхУчетаНДС поставлялся без исходных текстов. Это было одним из отличий базовых версий от ПРОФ, часто используемым для ограничения функционала.
Постепенное распространение на ПРОФ версии: Долгое время профессиональные версии конфигураций 1С считались полностью открытыми для модификации, за исключением некоторых специализированных компонентов или драйверов. Однако, последние обновления, в частности релиз 149, демонстрируют, что практика закрытия кода начинает активно применяться и в ПРОФ версиях. Это вызывает наиболее активное обсуждение, поскольку затрагивает широкий круг разработчиков, привыкших к полному доступу к коду.
Закрытие модулей интеграции: Некоторые пользователи утверждают, что модули интеграции в ПРОФ версиях также закрывались и раньше, хотя и не столь массово. Однако другие данные показывают, что в базах БП ПРОФ 2018 года многие модули интеграции были открыты. Это говорит о том, что хотя прецеденты и были, текущая тенденция является более выраженной и систематичной.
Таким образом, мы приходим к выводу, что закрытие кода — не абсолютно новое явление для платформы 1С. Однако его распространение на ПРОФ версии и на более широкий круг типовых модулей, особенно тех, что связаны с критически важными функциями, является относительно новой и значимой тенденцией.
Изучим основные мотивы, которые могут побуждать фирму 1С к закрытию исходного кода типовых модулей. Участники обсуждения и дополнительная информация из интернета выделяют несколько ключевых причин:
Защита интеллектуальной собственности и предотвращение несанкционированных изменений:
Сохранение ценности продукта: Закрытие кода помогает 1С защищать свои уникальные разработки и алгоритмы от копирования или использования без лицензии. Это позволяет поддерживать ценность и конкурентоспособность платформы и типовых решений.
Снижение рисков "костылей": Открытый код часто приводит к тому, что разработчики на стороне клиентов вносят прямые изменения в типовые модули. Такие изменения, часто называемые "костылями", могут быть неоптимальными, содержать ошибки, а главное — вызывать проблемы при обновлении конфигурации. Закрывая код, 1С минимизирует возможность внесения таких некачественных изменений, а для управления остальными доработками полезно объединение модулей в разрезе методов.
Повышение стабильности и управляемости: Когда критически важные модули закрыты, 1С может быть уверена, что их логика не была изменена. Это упрощает процесс тестирования новых релизов и обновлений, а также гарантирует предсказуемое поведение системы.
Сокращение обращений в техподдержку: Значительная часть обращений в техническую поддержку 1С связана с ошибками, возникшими из-за некорректных модификаций типового кода. Закрытие модулей способствует снижению таких обращений, позволяя техподдержке сосредоточиться на системных проблемах.
Соответствие требованиям регулирующих органов (ФНС, ЕГАИС, Честный Знак):
Безопасность и неразглашение данных: Модули, отвечающие за интеграцию с государственными информационными системами (например, ФНС, ЕНС, Честный Знак), могут содержать чувствительные алгоритмы, ключи шифрования или механизмы взаимодействия, которые подлежат строгой защите. Регулирующие органы могут требовать от 1С обеспечить невозможность модификации или реверс-инжиниринга этих компонентов. Закрытие кода в этом случае является мерой безопасности, направленной на соблюдение NDA (соглашений о неразглашении) и предотвращение утечек или несанкционированных манипуляций.
Гарантия соответствия: Закрытый код также гарантирует, что функционал, соответствующий законодательным требованиям, остается неизменным, и клиенты будут сдавать отчетность или обмениваться данными в строгом соответствии с регламентами.
Ограничение функционала и лицензионная политика:
Разделение версий: В базовых версиях конфигураций 1С закрытие кода уже давно использовалось для ограничения функционала по сравнению с версиями ПРОФ. Это позволяет предлагать более доступные решения для небольших предприятий с ограниченными потребностями.
Пример модуля "РасчетЗарплатыДляНебольшихОрганизаций": Этот модуль, как предполагается, был закрыт для того, чтобы пользователи не могли снять ограничения на количество сотрудников, предусмотренные лицензионной политикой для определенных версий конфигураций. Это яркий пример использования закрытия кода для enforcement'а лицензионных условий.
Упрощение обновлений и поддержки:
Контролируемое развитие: Закрытые модули позволяют 1С более контролируемо развивать и обновлять стандартный функционал, минимизируя риски возникновения ошибок из-за несовместимости с кастомными изменениями. Разработчикам 1С становится легче предсказывать поведение системы в новых релизах.
Мы видим, что за закрытием кода стоит целый комплекс причин, от технических и организационных до юридических и коммерческих. Это не просто прихоть разработчика, а часть целенаправленной стратегии 1С.
Теперь рассмотрим технические детали, связанные с закрытыми модулями, и обсудим, какие возможности остаются у разработчиков.
Что означает "скомпилированный байт-код"?
Когда мы говорим, что модуль поставляется в виде скомпилированного байт-кода, это означает, что исходный текст на встроенном языке 1С был преобразован в промежуточный машинонезависимый формат, который может быть интерпретирован виртуальной машиной 1С:Предприятия. По сути, это похоже на то, как Java-код компилируется в байт-код для JVM. Из этого байт-кода напрямую получить оригинальный исходный текст невозможно или крайне сложно.
На Хабре мы находим статьи, подробно описывающие внутреннее устройство байт-кода 1С, например, https://habr.com/ru/articles/489392/. Эти материалы помогают понять, что байт-код — это не просто шифрованный текст, а совершенно другая форма представления программы.
Декомпиляция байт-кода:
Несмотря на отсутствие исходного текста, существуют методы и инструменты для декомпиляции байт-кода 1С. Эти инструменты позволяют попытаться восстановить подобие исходного кода, то есть получить некоторое представление о логике работы закрытого модуля.
Важно понимать: Результат декомпиляции редко является полностью идентичным оригинальному исходному тексту. Он может быть менее читаемым, содержать обфусцированные имена переменных и процедур, а также не полностью воспроизводить все нюансы синтаксиса встроенного языка. Это связано с тем, что часть информации теряется в процессе компиляции.
Практическое применение: Декомпиляция может быть полезна для анализа логики модуля в случаях, когда нет другой возможности понять его работу (например, для локализации ошибки или интеграции). Однако это не является официальным или рекомендуемым методом работы и требует значительных навыков.
Влияние на отладку и исправление ошибок:
Один из самых болезненных аспектов закрытого кода для разработчиков — это затрудненная отладка. При возникновении ошибки в закрытом модуле мы не можем пошагово пройтись по его коду, чтобы понять причину сбоя, даже если задействован помощник отладки.
В таких ситуациях мы вынуждены полагаться на внешние признаки ошибки (сообщения, параметры вызова, контекст), а также на обновления конфигурации от 1С. Если ошибка связана с самим закрытым модулем, единственным надежным решением часто является установка нового релиза, в котором эта ошибка, возможно, уже исправлена. Альтернативно, как мы уже отмечали, можно попытаться проанализировать декомпилированный код для локализации проблемы, но это трудоемкий и неофициальный путь.
Таким образом, мы понимаем, что закрытие кода создает определенные сложности, но не делает работу с системой полностью невозможной. Нам необходимо искать другие, более официальные и стабильные пути взаимодействия.
Подробно разберем официальный и наиболее рекомендуемый фирмой 1С подход для работы с закрытыми модулями — использование расширений конфигураций и специальный конвертер расширения конфигурации в патч. Этот механизм создан специально для адаптации типовых решений без изменения самой конфигурации, что становится особенно актуальным в условиях закрытого кода.
Принцип работы расширений с закрытыми модулями:
Мы выясняем, что расширения конфигураций по-прежнему могут переопределять (расширять, изменять) процедуры и функции, экспортируемые из закрытых модулей. Это значит, что несмотря на отсутствие доступа к внутреннему коду, мы можем влиять на поведение закрытых модулей, вмешиваясь в их логику до, после или вместо выполнения определенных экспортных методов.
Это подтверждается на практике: "Проверил на тестовой. То есть, можно перехватывать процедуры и функции из закрытых модулей. Только надо знать имя и параметры." (Сообщение 64). Это ключевая информация для всех разработчиков.
Условия для успешного переопределения:
Знание имени процедуры/функции: Мы обязаны точно знать имя той экспортной процедуры или функции, которую хотим перехватить. Эти имена обычно остаются стабильными между релизами, но их приходится узнавать из документации, по косвенным признакам или, в крайнем случае, через анализ декомпилированного кода.
Знание сигнатуры (параметров): Кроме имени, мы также должны точно воспроизвести сигнатуру переопределяемой процедуры или функции, то есть количество и типы ее параметров. Если сигнатура не совпадает, расширение не сможет корректно перехватить метод, и мы получим ошибку.
Пример концепции переопределения с помощью расширений:
Предположим, у нас есть закрытый модуль, в котором экспортируется процедура ВыполнитьРасчет(Параметр1, Параметр2). В нашем расширении мы можем использовать следующие директивы для вмешательства:
// В модуле объекта расширения или в общем модуле расширения
// Перехват до выполнения оригинальной процедуры
&Перед("ИмяЗакрытогоМодуля.ВыполнитьРасчет")
Процедура ВыполнитьРасчет_Перед(Параметр1, Параметр2)
// Здесь мы можем изменить Параметр1 или Параметр2 перед тем, как они попадут
// в оригинальную процедуру закрытого модуля, или выполнить какую-либо
// дополнительную логику.
Сообщить("Выполняется код ПЕРЕД процедурой ВыполнитьРасчет");
КонецПроцедуры
// Полная замена оригинальной процедуры
&Вместо("ИмяЗакрытогоМодуля.ВыполнитьРасчет")
Процедура ВыполнитьРасчет_Вместо(Параметр1, Параметр2)
// Весь код оригинальной процедуры будет проигнорирован.
// Мы полностью замещаем его своей логикой.
Сообщить("Выполняется код ВМЕСТО процедуры ВыполнитьРасчет");
// Можем вызвать свою реализацию или просто вернуть управление.
// Например, выполнить свой расчет:
// Результат = МойНовыйРасчет(Параметр1, Параметр2);
КонецПроцедуры
// Перехват после выполнения оригинальной процедуры
&После("ИмяЗакрытогоМодуля.ВыполнитьРасчет")
Процедура ВыполнитьРасчет_После(Параметр1, Параметр2)
// Здесь мы можем обработать результаты выполнения оригинальной процедуры,
// или выполнить дополнительную логику после ее завершения.
Сообщить("Выполняется код ПОСЛЕ процедуры ВыполнитьРасчет");
КонецПроцедуры
Обратите внимание, что ИмяЗакрытогоМодуля должно быть полным именем общего модуля, например, ОбщийМодуль.ЕдиныйНалоговыйСчетИнтеграцияФормыПереопределяемый.
Преимущества расширений:
Сохранение типовой конфигурации: Главное преимущество состоит в том, что мы не вносим изменения непосредственно в типовую конфигурацию. Это резко упрощает процесс ее обновления, так как не нужно беспокоиться о слиянии изменений.
Поддержка со стороны 1С: Использование расширений является официально поддерживаемым и рекомендуемым способом адаптации. Это дает нам уверенность в том, что такой подход будет работать и развиваться в будущих версиях платформы.
Модульность и переносимость: Расширения позволяют нам создавать более модульные и переносимые решения, которые легко подключаются и отключаются от различных конфигураций, особенно если использовать удаление расширений универсальное.
Ограничения расширений с закрытыми модулями:
Мы не можем напрямую модифицировать внутреннюю логику закрытого модуля, если она не экспортирована. Нам доступно только вмешательство в точки вызова экспортируемых процедур и функций.
Требуется глубокое понимание API закрытого модуля. Если нет документации, это может стать вызовом, требующим анализа поведения или даже использования декомпиляции для восстановления сигнатур.
Изменение сигнатуры экспортной процедуры в новом релизе 1С может привести к неработоспособности нашего расширения, требуя его адаптации.
Таким образом, мы заключаем, что расширения являются нашим основным и наиболее надежным инструментом для работы с закрытыми модулями, позволяя нам сохранять гибкость и адаптировать функционал, не нарушая целостности типового решения.
Проанализируем, какие долгосрочные последствия и тенденции могут быть связаны с увеличением числа закрытых модулей в 1С:
Эволюция платформы и стандартизация:
Закрытие кода является частью общей стратегии 1С по переходу к более стандартизированным, управляемым и безопасным решениям. Это может быть направлено на упрощение поддержки и развитие платформы в целом, а также на повышение качества типовых продуктов. 1С стремится к тому, чтобы ее конфигурации воспринимались как готовые коробочные продукты с четко определенными точками расширения, а не как каркас для любых модификаций.
Мы видим, что это соответствует мировым тенденциям в области разработки корпоративного ПО, где поставщики часто закрывают критически важные части своих систем, предоставляя лишь API для интеграции и расширения.
Изменения для разработчиков 1С:
Эта тенденция требует от нас, разработчиков, большей гибкости и переориентации. Нам необходимо осваивать и активно использовать механизмы расширений, а также другие официальные методы адаптации, такие как подписки на события, дополнительные отчеты и обработки. Прямое изменение типового кода будет становиться все менее приемлемым и все более рискованным.
Мы будем вынуждены уделять больше внимания документированию API типовых решений, а также тщательнее тестировать совместимость наших расширений с новыми релизами конфигураций.
Влияние на мелкий и средний бизнес:
Некоторые участники дискуссии высказывают предположение, что эта тенденция может сигнализировать о переходе стандартных конфигураций 1С в "другую весовую категорию", ориентированную на более крупные и требовательные к стабильности компании. "Не для ларьков", как отмечают на форуме.
Для очень мелкого бизнеса, возможно, в будущем появятся еще более упрощенные или облачные решения, возможно, даже напрямую на сайте ФНС, где бухгалтерский учет будет максимально автоматизирован и не будет требовать глубокой кастомизации с помощью кода 1С. Это может привести к тому, что "классические" конфигурации 1С станут менее доступны или привлекательны для самого малого бизнеса, который ранее мог позволить себе небольшие доработки.
Мы заключаем, что закрытие кода — это не просто техническое изменение, а стратегический шаг 1С, который будет иметь далекоидущие последствия для всей экосистемы платформы и требовать от всех участников рынка адаптации к новым реалиям.
Мы проанализировали тему закрытия исходного кода типовых модулей в конфигурациях 1С и пришли к следующим ключевым выводам:
Закрытие кода является частью стратегии фирмы 1С, направленной на защиту интеллектуальной собственности, обеспечение стабильности продукта, соответствие регуляторным требованиям (например, ФНС и Честный Знак) и улучшение управляемости обновлениями. Хотя практика закрытия модулей существовала в базовых версиях давно, сейчас мы наблюдаем ее распространение на профессиональные версии конфигураций, что вызывает справедливые вопросы у сообщества разработчиков.
Несмотря на возникающие сложности с отладкой и прямым изменением кода, основной и официально поддерживаемый механизм адаптации — это расширения конфигураций. Мы убедились, что расширения позволяют переопределять экспортные процедуры и функции из закрытых модулей, при условии, что мы точно знаем их имена и сигнатуры. Это требует от разработчиков более глубокого понимания API типовых решений и активного использования инструментов расширений вместо прямой модификации кода.
В целом, эта тенденция символизирует эволюцию платформы 1С к более стандартизированным и контролируемым решениям, что в долгосрочной перспективе призвано повысить надежность и качество программных продуктов 1С. Нам, как разработчикам, необходимо адаптироваться к этим изменениям, осваивать новые подходы и фокусироваться на разработке решений, максимально совместимых с типовыми конфигурациями и устойчивых к их обновлениям.