Статистика 1С или насколько глубока кроличья нора
В своей работе я регулярно сталкиваюсь с различными конфигурациями 1С. Часто приходится выгружать/загружать dt, готовить cf файлы обновлений для клиентов. Раньше я не придавала особого значения размеру конфигурации на диске, т.к было достаточного много места, но сейчас возникла острая нехватка свободного пространства. Это побудило меня поглубже узнать как устроены конфигурации изнутри, что у них общего, а чем отличаются и главное, из чего складывается размер. Речь пойдет про анализ наиболее популярных конфигураций с точки зрения разнообразной статистики. Как известно, платформа 8.3.10 получила функционал выгрузки конфигурации в файлы. Иными словами, мы можем выгрузить все метаданные конфигурации в файлы для дальнейшего исследования.
Для начала, давайте определимся с объектами исследования. К первой группе относятся популярные решения в новой редакции на управляемых формах: УТ 11.4, БП 3.0, ЗУП КОРП 3.1, ERP 2.5, а также Управление холдингом и библиотека стандартных подсистем (БСП). Вторая группа содержит те же самые конфигурации, но в старой редакции на обычных формах: УТ 10.3, БП 2.0, ЗУП КОРП 2.5 и УПП 1.3. Конфигурации обновлены до последних версий. Итак, начнем.
Часть 1. Структура выгрузки
Выгрузка конфигурации производится довольно просто — в контекстном меню «Конфигурация» выбираем пункт «Выгрузить конфигурацию в файлы» и указываем каталог, куда будут выгружены метаданные. Структура на диске будет выглядеть примерно так:
А вот пример структуры выгруженного справочника «Номенклатура»:
Файлы с расширением bsl содержат код на языке 1С, например, ManagerModule.bsl — модуль менеджера, а ObjectModule.bsl это модуль объекта. Формы выгружаются в xml. Обычная форма выгружается в файл формата bin, который содержит разметку элементов и код, в то время как управляемые формы выгружаются на 2 отдельных файла — файл разметки элементов в форма xml и модуль самой формы. Стоит отменить, что xml это распространенный формат в 1С, в нем хранятся формы, макеты печатных форм, классификаторы и другие свойства конфигурации.
Часть 2. Анализ размеров
Первое, с чего мы начнем, это сравним размеры выгрузок конфигураций:
И для сравнения, эти же конфигурации, но в старой редакции:
В заключении давайте сравним размер между старыми и новыми редакциями:
Как мы видим, решения в новой редакции занимают больше места, чем в старой. Я не буду глубоко вдаваться в подробности по какой причине это случилось, скажу лишь то, что управляемое приложение требует разделение кода на клиент и сервер, а это повлекло за собой количество файлов и увеличение размера. Для примера, бухгалтерия в старой редакции 2.0 содержит 4,6 тыс. модулей, тогда как БП 3.0 содержит уже 11,5 тыс. модулей. Также хочу напомнить, что фирма 1С полноценно поддерживает и развивает только новые редакции, а старые минимально, для сдачи отчетности. Поэтому такая разница кода не дает объективной оценки.
Давайте капнем глубже и посмотрим из чего состоит самая большая конфигурация — ERP. На скриншоте фрагмент метаданных:
Из таблицы видно, что папка Reports весит больше всех остальных вместе взятых. Но честно признаться, это не новость, так как ключевая функция 1С это отчетность, а ее в России много и она часто меняется. Львиная доля это регламентированная отчетность, фрагмент:
Ответ почему отчеты занимают так много места кроется в том, что конфигурация, как оказалось, хранит формы отчетности за предыдущие годы. Например, Регламентированный отчет статистика форма П1:
Отсюда возникает 2 логичных вопроса: нужно ли хранить эти старые формы, и второй, какой прирост в размерах будет у конфигурации через 10 лет, ведь таких форм сотни и каждая весит в среднем по 10 Мб.
Теперь давайте сравним насколько отличается количество отчетов у конфигураций, которые сдают регламентированную отчетность:
Интересный момент: количество отчетов БП 2.0 и 3.0 отличается незначительно, могу предположить, что старая редакция все еще популярна и ее приходится поддерживать.
Вторую особенность, которую хочется подчеркнуть это папка CommonTemplates, в дереве метаданных это ОбщиеМакеты. В основном она содержит драйвера торгового оборудования (далее — ТО), макеты печатных форм и различные классификаторы. Пример фрагмента содержимого ERP:
И размер папки в разрезе конфигураций:
Обратите внимание, общие макеты УТ новой редакции опережает по размерам все конфигурации. Это объясняется тем, что решение заточено под розничную и оптовую торговлю, поэтому содержит большой спектр драйверов ТО, а это бинарные файлы, которые занимают много места. В УТ 11.4 общие макеты занимают более 30% от общего размера конфигурации:
Теперь давайте сравним общие макеты между редакциями:
Глядя на график ниже возникает вопрос — почему общие макеты в новых редакциях весят 300+ Мб? Почему драйвера ТО не хранят только те конфигурации, которые непосредственно взаимодействуют с ним? Например, Розница или та же самая Управление торговлей. А если посмотреть на БП 2.0 то она содержит минимум драйверов торгового оборудования, что вполне логично. Ответ довольно прост — в эти конфигурации подключена подсистема из БПО — библиотеки подключаемого оборудования. Это отдельное решение фирмы 1С, которое хранит в себе множество драйверов для самого разного оборудования. Можно долго рассуждать нужна она в каждой конфигурации или нет, но здесь работает принцип — лучше больше, чем меньше. Исключение из правил — ЗУП, оно и понятно: решение не для торговли.
Заключительные графики:
Подводя итоги можно сказать, что при одинаковой функциональности решения на управляемых формах существенно превосходят по размерам своих предшественников на обычных формах. Это обусловлено такими факторами как разделение кода на клиент и сервер, а также унификация конфигураций на основе БСП и БПО. И не стоит забывать, что фирма 1С полноценно развивает и продвигает решения именно на управляемых формах.
Часть 3. Анализ кодовой базы
Прежде чем приступить к анализу и сбору данных исходного кода конфигураций я решила оценить масштаб бедствия. За основу я сразу взяла erp и решила подсчитать количество модулей, которые мне предстоит обработать. В итоге вышло 17 тыс. файлов, каждый из которых содержит от нескольких строк до 98 тыс. строк кода. Средствами 1С я не решилась проводить анализ и хранение статистики и поэтому в качестве инструмента выбрала java и MySQL. До этого момента я никогда не анализировала столь крупные данные, плюс ко всему не было четкого понимания какие метрики наиболее интересны. Для себя я выделила следующие:
1. Кол-во процедур и функций (далее, вызовы)
2. Самые популярные вызовы
3. Рекордсмены среди методов и модулей по количеству кода
4. Самые длинные и короткие вызовы в плане написания
5. Количество кода в каждой конфигурации
В процессе изучения появились многие другие метрики, но обо всем по порядку.
Первое, с чего я начала это сбор данных по каждой процедуре и функции. Были проанализированы общие модули, модули формы, объектов и менеджеров и др. Для этого рекурсией необходимо обойти все каталоги и обработать файлы с расширением bsl и файлы bin для обычных форм. Для хранения данных по каждому методу я создала класс, который включал себя около 15 свойств, таких как имена методов и модулей, кол-во строк кода в методе, входящие параметры и другие. В целом, задача несложная, тренировка шла на конфигурации БСП. По мере загрузки информации появились нюансы, которые нужно было учитывать, например, в общих модулях БП 3.0 встречались невидимые символы, которые не позволяли корректно загрузить информацию о методах.
Вторая метрика, которая была полезна это частота вызовов каждого метода. Причем не просто количество, а еще откуда был произведен вызов. Этот сбор данных в общей массе занимал больше всего времени, т.к нужно было произвести поиск каждой функции во всех файлах с расширением bsl. Готовый, но медленный алгоритм получилось реализовать быстро, но скоростной на больших объемах данных, таких как erp, получилось написать только после 3–4 попыток. В итоге получилась вторая сущность которая хранила метод и список методов, из которого он вызывался. Эта таблица содержала ~1,7 млн строк — историю вызовов каждого метода всех 9 конфигураций. Обращаю ваше внимание, что статистика касается только общих методов, т.к их вызов можно точно идентифицировать благодаря паттерну ИмяМодуля.ИмяМетода (параметры, если есть). Статистику вызова методов модулей объектов, менеджеров и форм я не учитывала. Графики, изображённые ниже показывают объём и сравнение кода между конфигурациями:
И в заключении сравним объем кода старой и новой редакции:
Теперь можно сделать однозначный вывод, что количество строк кода в новых редакциях существенно больше чем в старых.
Далее рассмотрим статистику в разрезе методов:
График ниже особенно ярко указывает разницу в количестве методов между новыми и старыми редакциями:
Следующее, на чем хочется заострить внимание это длина методов и общих модулей. В типовых конфигурациях преобладают имена, содержащие общее описание (что делает этот метод), но зачастую эти имена имеют большую длину. Самый длинный вызов содержит 166 символов в написании. Вызывается всего 1 раз и встречается в УХ и БП 3.0 — РасчетЗарплатыДляНебольшихОрганизацийПереопределяемый.ТекстСообщенияОНевозможностиСоздаватьДокументыПриПревышенииМаксимальноДопустимогоКоличестваРаботающихСотрудников. Лично для меня, длинные имена общих модулей и методов это большая трудность, т.к я не знаю наизусть все вызовы, а контекстная подсказка при написании общего модуля отсутствует (но есть при вводе имени метода). И даже если я знаю как пишется нужный мне общий модуль — я запросто могу допустить опечатку и приходится возвращаться чтобы ее исправить. Возможно, контекстная подсказка есть в EDT, но я в ней не работаю и ближайшей время не планирую. На графике ниже статистика длины вызываемых общих методов в формате ИмяМодуля.ИмяМетода:
Если же мы посмотрим на имена самих процедур и функций, то картинка немного отличается. 30% методов имеют длину до 25 символов, но от 25 до 50 символов уже 60%:
Блиц по метрикам
10 тыс. строк кода содержит метод — УчетСтраховыхВзносов.СформироватьВТРасширенныеСведенияОДоходахИВзносах. Встречается в 3-х конфигурациях: БП 3.0, ЗУП 3.1, ERP 2.5, УХ 3.0.
98 тыс. строк содержит модуль объекта обработки ДокументооборотСКонтролирующимиОрганами. Эта обработка есть во всех решениях старой редакции. Рекордсмен по количеству строк кода в новой редакции — 79 тыс. строк в модуле формыКонтейнерКлиентскихМетодов этой же обработки.
В ERP 2.5 метод ВариантыОтчетовУТПереопределяемый.НастроитьВариантыОтчетов содержит больше всего вызовов других функций (670), но уникальных среди них всего 8.
Рекордсмен по уникальным вызовам это процедура из ЗУП 2.5 ПроцедурыОбновленияИнформационнойБазыПереопределяемый.ВыполнитьОбновление. В процедура вызывается 441 метод из которых 305(!) уникальные.
Самый короткий общий метод — ЧекиЕГАИС.ЧекXML (УТ 11.4). Также можно отменить ИнтеграцияИС.ДатаUTC (любая конфигурация в новой редакции)
Самый популярный метод — СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку (суммарно во всех конфигурация 16 тыс. вызовов). Также отмечу РегламентированнаяОтчетностьКлиентСервер.ОкруглитьЧислоПоФормату (8,5 тыс. вызовов). А на общий модуль «ОбщегоНазначения» приходится такие популярные методы как ЗначениеРеквизитаОбъекта, СообщитьПользователю, ОбщийМодуль и так далее, поэтому советую хорошо с ним ознакомиться.
Вместо выводов
Что можно сказать в заключении. Несмотря на непрерывное развитие конфигураций и универсальность под разные бизнес задачи, входной порог на доработку и адаптацию остается крайне высоким. И даже дело не в квалификации программиста, а в крайней запутанности. Если в собственных решениях, которые я пишу с 0, стараюсь писать максимально прозрачно, чтобы любой мог быстро вникнуть в работу механизмов проведения документов, синхронизации между другими конфигурациями или взаимодействие с сторонним API, то конфигурации 1С представляют собой монстра, и зачастую многие процессы представляют собой черный ящик. Я думаю, многим знакома ситуация, когда стек вызовов достигает нескольких десятков вызовов и очень трудно понять с чем связана такая сложность. Надо признать что это плата за универсальность решений, и конечно же, переход конфигураций на управляемое приложение. А какие трудности в разработке возникают у вас?
