Статистика 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.     10 самых популярных вызовов

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%:

Блиц по метрикам

  1. 10 тыс. строк кода содержит метод - УчетСтраховыхВзносов.СформироватьВТРасширенныеСведенияОДоходахИВзносах. Встречается в 3-х конфигурациях: БП 3.0, ЗУП 3.1, ERP 2.5, УХ 3.0.

  2. 98 тыс. строк содержит модуль объекта обработки ДокументооборотСКонтролирующимиОрганами. Эта обработка есть во всех решениях старой редакции. Рекордсмен по количеству строк кода в новой редакции – 79 тыс. строк в модуле формыКонтейнерКлиентскихМетодов этой же обработки.

  3. В ERP 2.5 метод ВариантыОтчетовУТПереопределяемый.НастроитьВариантыОтчетов содержит больше всего вызовов других функций (670), но уникальных среди них всего 8.

  4. Рекордсмен по уникальным вызовам это процедура из ЗУП 2.5 ПроцедурыОбновленияИнформационнойБазыПереопределяемый.ВыполнитьОбновление. В процедура вызывается 441 метод из которых 305(!) уникальные.

  5. Самый короткий общий метод - ЧекиЕГАИС.ЧекXML (УТ 11.4). Также можно отменить ИнтеграцияИС.ДатаUTC (любая конфигурация в новой редакции)

  6. Самый популярный метод - СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку (суммарно во всех конфигурация 16 тыс. вызовов). Также отмечу РегламентированнаяОтчетностьКлиентСервер.ОкруглитьЧислоПоФормату (8,5 тыс. вызовов). А на общий модуль «ОбщегоНазначения» приходится такие популярные методы как ЗначениеРеквизитаОбъекта, СообщитьПользователю, ОбщийМодуль и так далее, поэтому советую хорошо с ним ознакомиться.

Вместо выводов

Что можно сказать в заключении. Несмотря на непрерывное развитие конфигураций и универсальность под разные бизнес задачи, входной порог на доработку и адаптацию остается крайне высоким. И даже дело не в квалификации программиста, а в крайней запутанности. Если в собственных решениях, которые я пишу с 0, стараюсь писать максимально прозрачно, чтобы любой мог быстро вникнуть в работу механизмов проведения документов, синхронизации между другими конфигурациями или взаимодействие с сторонним API, то конфигурации 1С представляют собой монстра, и зачастую многие процессы представляют собой черный ящик. Я думаю, многим знакома ситуация, когда стек вызовов достигает нескольких десятков вызовов и очень трудно понять с чем связана такая сложность. Надо признать что это плата за универсальность решений, и конечно же, переход конфигураций на управляемое приложение. А какие трудности в разработке возникают у вас?

Источник: https://habr.com/ru/post/535662/


Интересные статьи

Интересные статьи

Летом 2019 года, любопытства ради, я стал логировать все свои действия — работу, сон, создание контента и т.п. Получился интересный результат — теперь я с цифрами в руках могу увидеть, на...
График аварийности езды с включенным и выключенным автопилотом в машинах Tesla, скорректированный для сравнения езды по городу и шоссе Каждый квартал Tesla публикует статистику о п...
Существует традиция, долго и дорого разрабатывать интернет-магазин. :-) Лакировать все детали, придумывать, внедрять и полировать «фишечки» и делать это все до открытия магазина.
В 1С Битрикс есть специальные сущности под названием “Информационные блоки, сокращенно (инфоблоки)“, я думаю каждый с ними знаком, но не каждый понимает, что это такое и для чего они нужны
Утилита Webalizer и инструмент Google Analytics помогали мне много лет получать представление о том, что происходит на веб сайтах. Сейчас я понимаю, что они дают очень мало полезной информации. И...