Каждый 1С-разработчик рано или поздно сталкивается с ситуацией, когда ему в наследство достается огромная, сильно переписанная база данных (например, Управление торговлей 11 или ERP), а спросить о том, кто, как и зачем ее дорабатывал, совершенно не у кого. Документация отсутствует, предыдущие программисты уволились, а задачи по поддержке и развитию системы нужно решать уже сейчас.
В этой статье мы подробно разберем системный подход к изучению незнакомой «нетленки». Мы объединили практический опыт разработчиков с форумов и профессиональные архитектурные методики анализа метаданных, чтобы составить пошаговое руководство, которое поможет вам войти в курс дела в кратчайшие сроки.
Прежде чем погружаться в дебри программного кода, нам необходимо понять, как именно предприятие использует эту информационную базу. Любая доработка создавалась под конкретную бизнес-потребность. Без понимания специфики процессов компании вы будете видеть код, но не поймете его истинного назначения.
Обойдем ключевых пользователей программы (руководителей отделов продаж, закупок, складских работников, бухгалтеров) и понаблюдаем за их ежедневной рутиной. Нам важно выяснить:
Особое внимание уделим вопросам «зачем» и «для чего». Очень часто программисты дорабатывают сложные цепочки документов только потому, что пользователи не знали о существовании типового функционала. Понимание реальных потребностей бизнеса сэкономит вам недели копания в коде.
После того как мы получили общее представление о бизнесе, перейдем к техническому анализу в конфигураторе. Нам нужно четко локализовать места, куда вмешивались наши предшественники.
Если конфигурация находится на поддержке, выполним сравнение с конфигурацией поставщика:
В открывшемся окне сравнения мы увидим дерево метаданных, где измененные или добавленные объекты будут отмечены специальными значками. Нам необходимо зафиксировать:
Если конфигурация полностью снята с поддержки, ситуация усложняется. В этом случае нам придется найти чистую типовую конфигурацию той же версии и выполнить сравнение через файл конфигурации (*.cf). На основе полученного списка изменений составим карту доработок.
В современных конфигурациях на платформе 1С:Предприятие 8.3 правила хорошего тона предписывают вести разработку в расширениях или использовать подписки на события, чтобы не изменять типовой код напрямую. Если мы просто откроем модуль документа, мы можем не увидеть там никаких изменений, хотя логика его проведения полностью переписана.
Проанализируем расширения конфигурации. Перейдем в меню Конфигурация — Расширения конфигурации. Если расширения есть, изучим их структуру. Особое внимание обратим на процедуры, перехваченные с помощью аннотаций:
&Вместо — полностью заменяет типовой метод своим алгоритмом. Это самое критичное место, требующее детального анализа.&Перед и &После — выполняют кастомный код до или после работы типовой процедуры.Также исследуем ветку Подписки на события в дереве метаданных основной конфигурации. Отфильтруем подписки по интересующим нас объектам (например, по ключевым документам). Подписки на события ПередЗаписью, ПриЗаписи или ОбработкаПроведения часто используются для незаметного внедрения кастомных проверок и движений по регистрам. Это позволяет разработчикам не менять код самого документа, сохраняя возможность его обновления.
Зачастую до 80% всех доработок, сделанных в компании за долгие годы, со временем теряют актуальность. Пользователи, для которых они писались, увольняются, процессы меняются, а мертвый код продолжает висеть в базе, затрудняя обновления и создавая ошибки. Наша задача — отсеять живой функционал от заброшенного.
Для этого соберем статистику из Журнала регистрации (ЖР). Нам нужно проанализировать активность за последние несколько месяцев:
Если нам нужно отследить использование кастомных отчетов, которые не оставляют явных следов в типовом ЖР, мы можем временно внедрить простое логирование. Напишем небольшую процедуру в общем модуле, которая будет записывать факт открытия отчета или формы в специальный регистр сведений.
Один из самых эффективных практических приемов для выявления реальных пользователей доработанного функционала — это метод его постепенного и контролируемого ограничения. Вместо радикальных мер вроде удаления кода (что может привести к фатальным последствиям), применим более изящный подход.
Создадим резервную копию базы данных. На тестовой копии или непосредственно в рабочей базе (если мы уверены в безопасности операции) ограничим права доступа к подозрительным нетиповым объектам. Сделать это можно так:
Те пользователи, которым этот функционал действительно жизненно необходим для работы, незамедлительно обратятся к вам с вопросом. Это позволит вам точно определить круг заинтересованных лиц и предметно расспросить их о деталях работы с данными объектами.
Интерфейс программы и экранные формы могут быть обманчивы и запутаны. Профессиональный разработчик всегда начинает глубокий анализ логики с регистров. Именно регистры (накопления, сведений, расчета) отражают суть бизнес-процессов компании. Документы — это лишь средство ввода данных, а регистры — это сами данные.
Проанализируем движения ключевых документов:
ВыручкаИСебестоимостьПродаж, ТоварыНаСкладах, ВзаиморасчетыСКлиентами), сопоставим состав его реквизитов с ресурсами и измерениями этих регистров.Понимание структуры регистров дает мгновенный ответ на вопрос, зачем нужна доработка. Например, если мы видим новый регистр сведений ит_ДополнительныеСкидкиПокупателей, мы сразу понимаем, что в системе реализован кастомный механизм расчета скидок, и можем целенаправленно искать код, который читает данные из этого регистра при заполнении документов продаж.
Когда нам нужно разобраться в работе сложного алгоритма (например, расчета себестоимости, заполнения сложных табличных частей или интеграции с внешними системами), чтение сухого программного кода в конфигураторе малоэффективно. Нам поможет динамический анализ во время работы программы.
Используем встроенный инструмент Замер производительности. Это позволяет увидеть реальный путь прохождения программы по строкам кода:
Перед нами откроется таблица со списком всех процедур и функций, которые реально выполнились в процессе нашей операции. Мы увидим количество вызовов каждой строки и затраченное время. Это моментально подсветит кастомные общие модули и функции, задействованные в процессе, отсекая тысячи строк неиспользуемого типового кода.
Также не забудем настроить автоматическое подключение к фоновым заданиям. В современных решениях на БСП (включая УТ 11) тяжелые расчеты и обработки документов часто передаются на выполнение серверным фоновым заданиям. Чтобы отладчик останавливался на точках останова в таких модулях, настроим его параметры:
Разработчики, дорожащие своей репутацией, всегда маркируют свои доработки, чтобы их преемникам было проще ориентироваться в коде. Попробуем выполнить глобальный поиск по конфигурации на предмет префиксов.
Обычно компаниям или конкретным проектам присваивается буквенный префикс (например, ит_, дораб_, мск_, Project_). Сделаем глобальный поиск (сочетание клавиш Ctrl + Shift + F) по этим буквосочетаниям. Мы можем обнаружить:
ит_ОбщегоНазначения).// { ит Начало доработки ... // } ит Конец доработки.Также проанализируем модули с суффиксом Переопределяемый. Библиотека стандартных подсистем (БСП) предоставляет специальные точки интеграции для разработчиков. Например, кастомные алгоритмы заполнения объектов часто внедряются в общий модуль ЗаполнениеСвойствПереопределяемый, а кастомные печатные формы — в УправлениеПечатьюПереопределяемый. Изучение этих модулей позволит быстро локализовать все интеграционные точки доработок с типовой конфигурацией.
Используя предложенные методики комплексно, мы сможем поэтапно, от общего к частному, составить полную и достоверную картину состояния информационной базы, избавиться от неиспользуемого мусора и уверенно поддерживать доработанную систему.