← К списку

При работе с конфигурациями 1С:Предприятие мы часто сталкиваемся с необходимостью понять происхождение того или иного фрагмента кода. Это может быть как типовой код, так и доработка, выполненная сторонним разработчиком или нами самими много лет назад. Выяснить источник кода крайне важно для его анализа, модификации или отладки. Давайте вместе разберем различные подходы и инструменты, которые помогут нам в этом нелегком, но увлекательном деле.

Мы рассмотрим несколько эффективных методов, начиная от самых простых и заканчивая более сложными и специализированными. Каждый из них имеет свои преимущества и может быть применен в зависимости от ситуации.

1. Глобальный поиск по конфигурации

Это один из самых очевидных и часто используемых способов. Если у нас есть подозрительный фрагмент кода, мы можем просто найти его во всей конфигурации.

1. Выделите уникальный фрагмент: Для начала нам нужно взять максимально длинную и уникальную строчку или часть кода из интересующего нас модуля. Чем уникальнее фрагмент, тем меньше ложных срабатываний будет при поиске. Например, это может быть полное имя процедуры, функция, уникальная переменная или даже комментарий.
2. Используйте команду "Глобальный поиск": Откройте конфигуратор 1С. Мы найдем команду "Глобальный поиск" (обычно доступна через меню "Конфигурация" -> "Найти в конфигурации" или комбинацию клавиш Ctrl + Shift + F).
3. Вставьте искомый фрагмент: Скопируйте выделенный нами фрагмент текста и вставьте его в поле поиска.
4. Запустите поиск: Проведите поиск по всей конфигурации. Результаты поиска покажут нам все места, где встречается данный фрагмент кода. Это поможет определить, был ли он скопирован из другого модуля, является ли частью типового функционала, или же это уникальная доработка.

Посмотрим на пример: Предположим, мы нашли в коде вызов процедуры ОбновитьСтатусыЗаказовПоставщику(). Вставив это имя в глобальный поиск, мы сможем найти все места, где эта процедура определена или вызывается.

2. Анализ особенностей кода

Иногда сам код может дать нам подсказки о своем происхождении. Мы должны внимательно изучить его структуру и содержание.

1. Имена процедур и функций: Обратите внимание на имена процедур и функций. Часто разработчики используют определенные префиксы или стили именования для своих доработок. Например, если типовая процедура называется ЗаполнитьТабличнуюЧасть(), а мы видим _МояКомпания_ЗаполнитьТабличнуюЧастьДоп(), это явно указывает на доработку.
2. Названия областей: В модулях 1С часто используются области (например, #Область и #КонецОбласти) для структурирования кода. Названия этих областей могут содержать информацию о назначении кода или его авторе.
3. Директивы компиляции: Директивы, такие как &НаСервере, &НаКлиенте, &ВнешнееСоединение, могут подсказать нам, в каком контексте выполняется код. Например, наличие &НаСервере в модуле формы с большой вероятностью указывает на то, что это код серверной части формы.
4. Комментарии: Очень часто добросовестные разработчики оставляют комментарии с указанием автора, даты изменения, номера задачи или ссылки на техническое задание. Мы можем использовать глобальный поиск по таким комментариям, чтобы найти источник.
5. Особенности стиля/стандарта: Если в конфигурации используются общепринятые стандарты разработки (например, стандарты фирмы "1С"), любые отклонения от них могут указывать на код, пришедший из другого источника или написанный без соблюдения стандартов.

3. Сравнение и объединение конфигураций

Этот метод является одним из самых мощных для выявления изменений в типовых конфигурациях.

1. Встроенные средства 1С:

   Платформа 1С:Предприятие предоставляет нам инструмент "Сравнение и объединение" конфигураций. Мы можем использовать его для:

   • Сравнения с конфигурацией поставщика: Мы всегда можем сравнить нашу текущую конфигурацию с конфигурацией поставщика (стандартной, необновленной версией). Это позволит нам увидеть все объекты и модули, которые были изменены или добавлены. Различия в модулях будут подсвечены, что моментально укажет на доработанный код.
   • Сравнения с сохраненным файлом конфигурации: Если у нас есть резервная копия или файл конфигурации предыдущей версии, мы можем сравнить текущую конфигурацию с ней. Это поможет нам отследить изменения, внесенные между двумя версиями.

   При сравнении модулей мы увидим не только измененные строки, но и можем анализировать изменения в разрезе отдельных методов, что значительно упрощает поиск. Сравнение может быть выполнено как по именам объектов, так и по их внутренним идентификаторам (UUID).

2. Внешние инструменты:

   Для более детального сравнения и анализа различий, особенно если требуется работа с внешними обработками или отчетами, мы можем прибегнуть к помощи сторонних программ, например, KDiff3. Такие инструменты позволяют проводить построчное сравнение текстов и могут быть интегрированы с 1С.

4. Анализ истории изменений и версионирование

Иногда нам нужно не просто найти код, но и понять, кто и когда его изменил.

1. Журнал регистрации:

   В 1С существует Журнал регистрации, который фиксирует действия пользователей и фоновых задач в программе. Хотя он не покажет нам конкретные строки кода, он может подсказать, когда и какой пользователь изменял определенные объекты конфигурации (например, модули). Зная время изменения, мы сможем сузить круг поиска.

2. Механизм "История изменений" (Версионирование):

   Начиная с платформы 8.3.11, нам доступен мощный механизм "История изменений" или версионирование объектов. Он позволяет хранить все изменения реквизитов документов и других объектов. Мы можем:

   • Видеть все внесенные пользователем изменения.
   • Сравнивать несколько версий документа или объекта друг с другом.
   • Восстанавливать предыдущие версии.

   Настройка этой функции осуществляется в разделе "Администрирование" - "Общие настройки" - "История изменения". Если версионирование было включено для модулей или объектов, связанных с интересующим нас кодом, мы сможем увидеть, кто и когда его менял.

5. Статический анализ кода

Для больших и сложных конфигураций нам на помощь приходят специализированные инструменты.

Существуют инструменты статического анализа, такие как SonarQube с плагинами для 1С или 1С:Автоматизированная проверка конфигураций (1С:АПК). Они анализируют исходный код без его запуска и могут помочь нам в следующем:

• Выявлять проблемы в коде.
• Проверять соответствие стандартам разработки.
• Находить дублирующийся код, что может указывать на копирование фрагментов.
• Обнаруживать другие "запахи" кода, которые могут косвенно указывать на происхождение или стиль написания.

Использование таких инструментов помогает систематизировать анализ и выявить закономерности, которые вручную заметить сложно.

6. Стандарты разработки 1С

Если разработка велась с соблюдением стандартов 1С, это значительно упрощает задачу.

Мы должны выяснить, соблюдаются ли в конфигурации стандарты 1С (например, по именованию переменных, процедур, оформлению кода, использованию префиксов для доработанных объектов). Если да, то:

• Префиксы для доработок: Часто для доработанных объектов и процедур используются специальные префиксы (например, БЛ_ для "Бизнес-Логики"). Это позволяет легко отличить типовой код от модифицированного.
• Комментирование кода: Стандарты могут включать рекомендации по комментированию кода с указанием автора, даты создания, номера задачи и ее описания. Мы можем использовать глобальный поиск по таким комментариям, чтобы найти исходную задачу или разработчика.

7. Внешние компоненты

Иногда часть функционала может быть реализована вне 1С.

Мы должны помнить, что часть функционала может быть реализована во внешних компонентах (DLL-библиотеках), которые подключаются к 1С. Если анализируемый код взаимодействует с такими компонентами, их идентификация (например, по имени объекта, используемого при подключении) может указать на внешний источник функционала. Нам следует искать вызовы методов внешних объектов или процедуры, отвечающие за их загрузку и инициализацию.

8. Отладчик

Для динамического анализа кода нам пригодится отладчик.

Отладчик позволяет нам пошагово выполнять код, просматривать значения переменных, стек вызовов процедур и функций, а также контекст выполнения. Используя отладчик, мы можем:

• Понять логику работы кода.
• Определить, какие объекты и модули задействованы в процессе выполнения.
• Выяснить, откуда был вызван интересующий нас фрагмент, просматривая стек вызовов.

Это помогает нам не только понять "что" делает код, но и "как" он работает в реальном времени, что может дать ценные подсказки о его происхождении.

9. Понимание бизнес-логики

Прежде чем углубляться в технические детали, давайте посмотрим на проблему сверху.

Прежде чем мы начнем анализировать код, полезно понять, как изучаемый механизм работает в пользовательском режиме программы. Мы можем:

• Проанализировать пользовательский интерфейс, где задействован этот код.
• Понять, какую бизнес-задачу решает данный функционал.

Это поможет нам сделать выводы о важности и назначении различных фрагментов кода, а также сузить область поиска. Если мы понимаем, что код относится, например, к расчету себестоимости, мы будем искать его в модулях, связанных с учетом затрат или производством.

Используя комбинацию этих методов, мы значительно повысим наши шансы на успешное определение источника части кода модуля в 1С. Каждый из подходов дополняет другие, позволяя нам получить максимально полную картину.

← К списку