Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
В своей работе я регулярно сталкиваюсь с различными конфигурациями 1С. Часто приходится выгружать/загружать dt, готовить cf файлы обновлений для клиентов. Раньше я не придавала особого значения размеру конфигурации на диске, т.к было достаточного много места, но сейчас возникла острая нехватка свободного пространства. Это побудило меня поглубже узнать как устроены конфигурации изнутри, что у них общего, а чем отличаются и главное, из чего складывается размер. Речь пойдет про анализ наиболее популярных конфигураций с точки зрения разнообразной статистики. Как известно, платформа 8.3.10 получила функционал выгрузки конфигурации в файлы. Иными словами, мы можем выгрузить все метаданные конфигурации в файлы для дальнейшего исследования.
Для начала, давайте определимся с объектами исследования. К первой группе относятся популярные решения в новой редакции на управляемых формах: УТ 11.4, БП 3.0, ЗУП КОРП 3.1, ERP 2.5, а также Управление холдингом и библиотека стандартных подсистем (БСП). Вторая группа содержит те же самые конфигурации, но в старой редакции на обычных формах: УТ 10.3, БП 2.0, ЗУП КОРП 2.5 и УПП 1.3. Конфигурации обновлены до последних версий. Итак, начнем.
Часть 1. Структура выгрузки
Выгрузка конфигурации производится довольно просто – в контекстном меню «Конфигурация» выбираем пункт «Выгрузить конфигурацию в файлы» и указываем каталог, куда будут выгружены метаданные. Структура на диске будет выглядеть примерно так:
![](https://habrastorage.org/getpro/habr/upload_files/559/03f/a67/55903fa67d01f3129b873fe339040629.png)
А вот пример структуры выгруженного справочника «Номенклатура»:
![](https://habrastorage.org/getpro/habr/upload_files/718/a30/d4b/718a30d4b0d5cb355af053abf4dc3398.png)
Файлы с расширением bsl содержат код на языке 1С, на пример, ManagerModule.bsl – модуль менеджера, а ObjectModule.bsl это модуль объекта. Формы выгружаются в xml. Обычная форма выгружается в файл формата bin, который содержит разметку элементов и код, в то время как управляемые формы выгружаются на 2 отдельных файла - файл разметки элементов в форма xml и модуль самой формы. Стоит отменить, что xml это распространенный формат в 1С, в нем хранятся формы, макеты печатных форм, классификаторы и другие свойства конфигурации.
Часть 2. Анализ размеров
Первое, с чего мы начнем, это сравним размеры выгрузок конфигураций:
![](https://habrastorage.org/getpro/habr/upload_files/01b/90e/593/01b90e5937e38ef1d0cd80e570ee6a47.png)
И для сравнения, эти же конфигурации, но в старой редакции:
![](https://habrastorage.org/getpro/habr/upload_files/249/8df/2e9/2498df2e96c6eccf2b6a054943bb71fb.png)
В заключении давайте сравним размер между старыми и новыми редакциями:
![](https://habrastorage.org/getpro/habr/upload_files/977/d16/a1b/977d16a1b7f6f0b15b0246ec841b6d24.png)
Как мы видим, решения в новой редакции занимают больше места, чем в старой. Я не буду глубоко вдаваться в подробности по какой причине это случилось, скажу лишь то, что управляемое приложение требует разделение кода на клиент и сервер, а это повлекло за собой количество файлов и увеличение размера. Для примера, бухгалтерия в старой редакции 2.0 содержит 4,6 тыс. модулей, тогда как БП 3.0 содержит уже 11,5 тыс. модулей. Также хочу напомнить, что фирма 1С полноценно поддерживает и развивает только новые редакции, а старые минимально, для сдачи отчетности. Поэтому такая разница кода не дает объективной оценки.
Давайте капнем глубже и посмотрим из чего состоит самая большая конфигурация - ERP. На скриншоте фрагмент метаданных:
![](https://habrastorage.org/getpro/habr/upload_files/4e8/ac3/948/4e8ac3948673675dde9888b6d4243ade.png)
Из таблицы видно, что папка Reports весит больше всех остальных вместе взятых. Но честно признаться, это не новость, так как ключевая функция 1С это отчетность, а ее в России много и она часто меняется. Львиная доля это регламентированная отчетность, фрагмент:
![](https://habrastorage.org/getpro/habr/upload_files/a62/da0/cbf/a62da0cbf1eb2b8e2060915de755dd63.png)
Ответ почему отчеты занимают так много места кроется в том, что конфигурация, как оказалось, хранит формы отчетности за предыдущие годы. На пример, Регламентированный отчет статистика форма П1:
![](https://habrastorage.org/getpro/habr/upload_files/0b5/1f9/12f/0b51f912fcb6bc95895d697368a883b4.png)
Отсюда возникает 2 логичных вопроса: нужно ли хранить эти старые формы, и второй, какой прирост в размерах будет у конфигурации через 10 лет, ведь таких форм сотни и каждая весит в среднем по 10 Мб.
Теперь давайте сравним насколько отличается количество отчетов у конфигураций, которые сдают регламентированную отчетность:
![](https://habrastorage.org/getpro/habr/upload_files/0ee/a0c/d54/0eea0cd54b2fd955bc8a5dd2040f01ac.png)
Интересный момент: количество отчетов БП 2.0 и 3.0 отличается незначительно, могу предположить, что старая редакция все еще популярна и ее приходится поддерживать.
Вторую особенность, которую хочется подчеркнуть это папка CommonTemplates, в дереве метаданных это ОбщиеМакеты. В основном она содержит драйвера торгового оборудования (далее – ТО), макеты печатных форм и различные классификаторы. Пример фрагмента содержимого ERP:
![](https://habrastorage.org/getpro/habr/upload_files/ddd/0fc/013/ddd0fc01325350af5b1f0e5a5fa5984a.png)
И размер папки в разрезе конфигураций:
![](https://habrastorage.org/getpro/habr/upload_files/af4/c76/ee6/af4c76ee686fe95f69667ff0c674075a.png)
Обратите внимание, общие макеты УТ новой редакции опережает по размерам все конфигурации. Это объясняется тем, что решение заточено под розничную и оптовую торговлю, поэтому содержит большой спектр драйверов ТО, а это бинарные файлы, которые занимают много места. В УТ 11.4 общие макеты занимают более 30% от общего размера конфигурации:
![](https://habrastorage.org/getpro/habr/upload_files/b5a/11d/3b6/b5a11d3b675100c268d469d73c3c74d9.png)
Теперь давайте сравним общие макеты между редакциями:
![](https://habrastorage.org/getpro/habr/upload_files/579/615/541/57961554162b13505ed678046683c44d.png)
Глядя на график ниже возникает вопрос – почему общие макеты в новых редакциях весят 300+ Мб? Почему драйвера ТО не хранят только те конфигурации, которые непосредственно взаимодействуют с ним? На пример, Розница или та же самая Управление торговлей. А если посмотреть на БП 2.0 то она содержит минимум драйверов торгового оборудования, что вполне логично. Ответ довольно прост – в эти конфигурации подключена подсистема из БПО – библиотеки подключаемого оборудования. Это отдельное решение фирмы 1С, которое хранит в себе множество драйверов для самого разного оборудования. Можно долго рассуждать нужна она в каждой конфигурации или нет, но здесь работает принцип – лучше больше, чем меньше. Исключение из правил – ЗУП, оно и понятно: решение не для торговли.
Заключительные графики:
![](https://habrastorage.org/getpro/habr/upload_files/514/bf6/0be/514bf60be206c4864578da26311eb5ea.png)
![](https://habrastorage.org/getpro/habr/upload_files/1b8/f67/89a/1b8f6789ad26b6b01bb6f3dc25953f2a.png)
Подводя итоги можно сказать, что при одинаковой функциональности решения на управляемых формах существенно превосходят по размерам своих предшественников на обычных формах. Это обусловлено такими факторами как разделение кода на клиент и сервер, а также унификация конфигураций на основе БСП и БПО. И не стоит забывать, что фирма 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 конфигураций. Обращаю ваше внимание, что статистика касается только общих методов, т.к их вызов можно точно идентифицировать благодаря паттерну ИмяМодуля.ИмяМетода(параметры, если есть). Статистику вызова методов модулей объектов, менеджеров и форм я не учитывала. Графики, изображённые ниже показывают объём и сравнение кода между конфигурациями:
![](https://habrastorage.org/getpro/habr/upload_files/6c2/605/8ae/6c26058ae4af6fff46078deae36ec8f8.png)
![](https://habrastorage.org/getpro/habr/upload_files/788/073/141/78807314191878bf81416cdb55478c58.png)
И в заключении сравним объем кода старой и новой редакции:
![](https://habrastorage.org/getpro/habr/upload_files/bb5/0eb/744/bb50eb74474e2ef76d975d35ee7ae299.png)
Теперь можно сделать однозначный вывод, что количество строк кода в новых редакциях существенно больше чем в старых.
Далее рассмотрим статистику в разрезе методов:
![](https://habrastorage.org/getpro/habr/upload_files/015/a24/d2a/015a24d2a611672a70140e4149e9fa69.png)
![](https://habrastorage.org/getpro/habr/upload_files/454/2b8/a79/4542b8a7992cb23598f983f7192b9fab.png)
График ниже особенно ярко указывает разницу в количестве методов между новыми и старыми редакциями:
![](https://habrastorage.org/getpro/habr/upload_files/106/c72/ab6/106c72ab61e3ec5fc57d1508b482a850.png)
Следующее, на чем хочется заострить внимание это длина методов и общих модулей. В типовых конфигурациях преобладают имена, содержащие общее описание(что делает этот метод), но зачастую эти имена имеют большую длину. Самый длинный вызов содержит 166 символов в написании. Вызывается всего 1 раз и встречается в УХ и БП 3.0 - РасчетЗарплатыДляНебольшихОрганизацийПереопределяемый.ТекстСообщенияОНевозможностиСоздаватьДокументыПриПревышенииМаксимальноДопустимогоКоличестваРаботающихСотрудников. Лично для меня, длинные имена общих модулей и методов это большая трудность, т.к я не знаю наизусть все вызовы, а контекстная подсказка при написании общего модуля отсутствует (но есть при вводе имени метода). И даже если я знаю как пишется нужный мне общий модуль - я запросто могу допустить опечатку и приходится возвращаться чтобы ее исправить. Возможно, контекстная подсказка есть в EDT, но я в ней не работаю и ближайшей время не планирую. На графике ниже статистика длины вызываемых общих методов в формате ИмяМодуля.ИмяМетода:
![](https://habrastorage.org/getpro/habr/upload_files/ccd/75e/795/ccd75e795ef8be7cfef94d80148cbfa2.png)
Если же мы посмотрим на имена самих процедур и функций, то картинка немного отличается. 30% методов имеют длину до 25 символов, но от 25 до 50 символов уже 60%:
![](https://habrastorage.org/getpro/habr/upload_files/cb0/4a0/d40/cb04a0d40c25e3d5cb73ee68b9dc77c0.png)
Блиц по метрикам
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С представляют собой монстра, и зачастую многие процессы представляют собой черный ящик. Я думаю, многим знакома ситуация, когда стек вызовов достигает нескольких десятков вызовов и очень трудно понять с чем связана такая сложность. Надо признать что это плата за универсальность решений, и конечно же, переход конфигураций на управляемое приложение. А какие трудности в разработке возникают у вас?