Развитие любой самописной или сильно кастомизированной конфигурации 1С рано или поздно проходит точку перегиба. Сначала система кажется легкой, понятной и быстро адаптируется под нужды бизнеса. Но со временем объем доработок растет, разработчики начинают забывать логику старых решений, а новые изменения ломают смежные разделы учета. Наступает так называемый технический хаос. Для оперативного контроля состояния учета после внесения изменений можно использовать автоматическое сравнение бухгалтерских и налоговых проводок между базами 1С.
В этой статье мы подробно разберем, по каким критериям конфигурацию можно официально считать «сложной», какими инструментами можно измерить этот уровень и как на понятном языке цифр доказать руководству необходимость выделения ресурсов на рефакторинг или привлечение технического архитектора.
Когда разработчики говорят руководству: «Мне сложно работать, я уже ничего не помню», бизнес часто воспринимает это как лень или некомпетентность. Чтобы разговор был конструктивным, необходимо перевести субъективные ощущения в объективные инженерные метрики сложности программного обеспечения.
Проанализируем ключевые метрики, которые используются в современной разработке:
Если, ИначеЕсли, циклы Для каждого, Пока, а также конструкции Попытка...Исключение увеличивают этот индекс. Если цикломатическая сложность модуля зашкаливает, код становится практически невозможно полностью покрыть тестами, а вероятность возникновения регрессионных ошибок при его изменении стремится к 100%.Для аргументации перед бизнесом отлично работают исторические сравнения. Вам нужно наглядно показать, как изменилась база за последние несколько лет (например, за 3–5 лет активной разработки).
Рассмотрим несколько простых и эффективных способов собрать эту статистику:
Способ 1. Сравнение выгрузки конфигураций в файлы XML
Этот метод позволяет увидеть точную картину изменения структуры метаданных и программного кода. Выгрузите текущую конфигурацию и ее архивную версию трехлетней давности в файлы (команда платформы «Конфигурация — Разгрузить конфигурацию в файлы...»).
После выгрузки вы можете сравнить каталоги с помощью сторонних утилит сравнения (например, WinMerge, Beyond Compare) или проанализировать количество файлов с расширением .bsl (модули) и .xml (описание объектов).
Способ 2. Подсчет строк кода (Lines of Code — LOC)
Хотя сам по себе объем кода не равен качеству, его взрывной рост показывает масштаб изменений. Чтобы подсчитать количество строк кода в модулях, можно воспользоваться утилитами командной строки. Например, перейдя в каталог с выгруженными bsl-файлами, можно запустить команду wc (для систем Linux/macOS или через Git Bash в Windows):
find . -name "*.bsl" | xargs wc -l
Это даст точную цифру строк кода тогда и сейчас. Разница в сотни тысяч строк будет наглядным подтверждением усложнения системы.
Способ 3. Анализ динамики хранилища конфигурации
Если разработка ведется в хранилище, сформируйте отчет по истории хранилища. Постройте простую таблицу или график, показывающий количество помещений (коммитов) по месяцам и количество измененных объектов. Рост интенсивности правок напрямую коррелирует с ростом энтропии системы.
Чтобы не изобретать велосипед, воспользуйтесь специализированным софтом для статического анализа кода. Это даст вам неоспоримые козыри в диалоге с руководством.
Для собственника бизнеса или генерального директора слова «красивый код» и «правильная архитектура» не имеют финансовой ценности. Разговор нужно вести на языке денег и бизнес-рисков. Выясним, как правильно выстроить аргументацию:
Аргумент 1. Показатель Time to Market (TtoM)
Объясните руководству: «Три года назад разработка нового отчета или бизнес-процесса занимала у нас 2 дня. Сейчас на это уходит 10 дней. Почему? Потому что 8 дней программист тратит на то, чтобы разобраться в хитросплетениях старого кода, локализовать неожиданно всплывшие ошибки в других отделах и согласовать логику с прошлыми доработками. Без архитектора эта цифра будет только расти, и скоро компания вообще не сможет быстро внедрять новые бизнес-идеи».
Аргумент 2. Общая стоимость владения (TCO — Total Cost of Ownership)
Покажите финансовую неэффективность текущего подхода. Из-за отсутствия единого архитектурного контроля разные разработчики пишут дублирующие функции, создают избыточные регистры или решают одну и ту же задачу взаимоисключающими методами. Компания платит за разработку одного и того же функционала дважды или трижды.
Аргумент 3. Риск критического сбоя системы (Bus Factor)
Если вся логика самописки держится в голове одного-двух программистов, бизнес находится под огромной угрозой. Внедрение роли архитектора, ведение актуальной технической документации и проведение обязательного Code Review (взаимного контроля кода) распределяет знания о системе внутри команды и минимизирует риски остановки учета.
Если вам удалось согласовать изменения, или если вы хотите начать наводить порядок своими силами, обратите внимание на правильные паттерны проектирования в 1С. Рассмотрим, как уйти от хаоса на примере часто встречающейся проблемы: разделение логики для разных организаций холдинга.
Плохая практика (хардкод в модулях):
Часто программисты встраивают условия под конкретные организации прямо в код проведения документов или расчета цен:
Если Объект.Организация = Справочники.Организации.НайтиПоРеквизиту("ИНН", "7701010101") Тогда
// Особый расчет для ООО "Ромашка"
ВыполнитьСпецифичныйРасчетДляРомашки();
ИначеЕсли Объект.Организация = Справочники.Организации.НайтиПоРеквизиту("ИНН", "7702020202") Тогда
// Особый расчет для ООО "Василек"
ВыполнитьСпецифичныйРасчетДляВасилька();
КонецЕсли;
Этот подход ведет к катастрофе. При добавлении нового юрлица программистам придется перерывать весь код конфигурации в поисках подобных конструкций.
Хорошая практика (использование фича-флагов и регистров настроек):
Правильный архитектурный подход заключается в вынесении логики в настройки. Создадим регистр сведений или используем механизм функциональных опций:
ПараметрыУчета = РегистрыСведений.НастройкиУчетнойПолитикиОрганизаций.ПолучитьНастройки(Объект.Организация);
Если ПараметрыУчета.ПрименятьОсобыйАлгоритмРасчета Тогда
// Универсальный вызов, завязанный на настройки, а не на конкретные ссылки или ИНН
ВыполнитьРасчетПоПравилу(ПараметрыУчета.ИдентификаторПравила);
КонецЕсли;
Такой подход позволяет подключать новые филиалы и организации силами пользователей или аналитиков через режим «1С:Предприятие», вообще не прибегая к изменению программного кода и сохраняя архитектурную чистоту вашей самописной конфигурации.