Вопрос использования жестко прописанных уникальных идентификаторов (GUID) в программном коде — это классическая дилемма между «быстрым результатом» и «качественной архитектурой». Часто разработчики поддаются соблазну использовать УникальныйИдентификатор для подстановки конкретных значений (например, склада по умолчанию или определенной статьи затрат), чтобы избежать поиска по наименованию. В этой статье мы подробно разберем, почему этот подход считается спорным, какие риски он несет и как реализовать подобную задачу методологически верно.
Прежде всего, проанализируем техническую сторону вопроса. В среде разработчиков часто возникает путаница между двумя методами. Разберем их различия, чтобы понимать, о чем именно идет речь в контексте «хардкода».
НайтиПоИдентификатору() — это метод коллекций форм (например, табличных частей или деревьев значений). Он ищет строку в визуальном элементе по ее внутреннему индексу сеанса. К бизнес-данным в базе он отношения практически не имеет.ПолучитьСсылку() менеджера справочника — именно его используют для получения ссылки на объект по строковому представлению GUID. Например: Справочники.Склады.ПолучитьСсылку(Новый УникальныйИдентификатор("...")).Когда говорят о «поиске по идентификатору» в коде, обычно подразумевают создание ссылки на основе заранее известного GUID. Рассмотрим, почему это может стать проблемой в будущем.
Проанализируем основные аргументы против «зашивания» идентификаторов в алгоритмы. Большинство опытных разработчиков сходятся во мнении, что это делает систему хрупкой и труднообслуживаемой.
Во-первых, это проблема «магических чисел» и читаемости кода. Когда другой программист (или вы сами через полгода) увидит строку типа "550e8400-e29b-41d4-a716-446655440000", он не поймет, что это за объект. Логика алгоритма становится непрозрачной. Чтобы понять, что это за склад или учетная запись, придется лезть в консоль запросов и искать объект в базе.
Во-вторых, риск «битых ссылок». Рассмотрим ситуацию: в базе проводится чистка данных или объединение дублей. Если администратор решит, что ваш «зашитый» элемент является дублем и удалит его (или заменит на другой с помощью стандартной обработки), код перестанет работать корректно. Метод ПолучитьСсылку() вернет объект типа «Объект не обнаружен», и программа выдаст ошибку или некорректный результат в самом неожиданном месте.
В-третьих, сложности при переносе данных. Если вы разработали функционал в тестовой базе и создали там элемент вручную, у него будет один GUID. При переносе кода в рабочую базу вам придется либо вручную создавать объект с тем же GUID (что требует специальных обработок), либо менять код. Это нарушает принцип независимости кода от данных.
Несмотря на строгие методологические запреты, существуют ситуации («военные условия»), когда такой подход может быть оправдан как временная мера или исключение:
Вместо того чтобы прописывать GUID в коде, рассмотрим правильные архитектурные решения. Проанализируем их по степени надежности и удобства.
Это самый простой и верный способ. Вы создаете константу в конфигураторе (например, ОсновнойСкладДляРозничнойТорговли), а в коде просто обращаетесь к ней. Пользователь сам выбирает нужный склад в настройках программы. Это позволяет менять значение без привлечения программиста.
Если настроек много, лучше использовать регистр сведений (например, «Настройки программы» или «Параметры алгоритмов»). Это более гибкий подход, позволяющий хранить настройки в разрезе организаций, пользователей или подразделений.
Если какой-то объект (например, ставка НДС «Без НДС» или «Основной склад») жизненно необходим для работы алгоритма, создайте его как предопределенный элемент в метаданных справочника. В коде вы сможете обращаться к нему напрямую: Справочники.Склады.ОсновнойСклад. Платформа сама позаботится о связи ссылки и метаданных.
Если вы все же вынуждены использовать GUID (например, из-за ограничений прав доступа или специфики внешней обработки), не пишите метод получения ссылки прямо в бизнес-логике. Выясним, как это оформить более культурно:
// Плохо:
Склад = Справочники.Склады.ПолучитьСсылку(Новый УникальныйИдентификатор("..."));
// Лучше: создать отдельную функцию с понятным названием
Функция ПолучитьСкладПоУмолчанию() Экспорт
Идентификатор = "550e8400-e29b-41d4-a716-446655440000"; // Обязательно комментарий, что это за склад
Возврат Справочники.Склады.ПолучитьСсылку(Новый УникальныйИдентификатор(Идентификатор));
КонецФункции
В современных версиях платформы (8.3.10 и выше) практически нет оправданий для «грязного» кода из-за закрытой конфигурации. Мы можем создать Расширение, добавить в него нужные константы или справочники и через механизм аннотаций (&Вместо, &После) внедрить свою логику в типовой процесс. Это позволяет сохранять основную базу на полной поддержке и при этом использовать чистые методы разработки.
Проанализировав ситуацию, можно сделать однозначный вывод: поиск по идентификатору (через ПолучитьСсылку по GUID) — это «технический долг», который рано или поздно приведет к ошибкам. Рассмотрим финальные рекомендации:
Помните, что хороший код — это код, который легко читать и который не ломается при обычном удалении помеченных объектов пользователем в интерфейсе.