Произвольные алгоритмы

Идея проста — повысить управляемость произвольными вспомогательными текстами кодов на встроенном языке. Да, мы пишем их в УПОБ и прочих обработках, вводим в полях разовых блоков, но рано или поздно возникает нужда в библиотеке наработок, просто кусков исполняемого кода, решающих конкретные задачи. Одним из вариантов такой библиотеки является справочник алгоритмов в составе простенькой подсистемы. Основные его достоинства:

• Каждому куску кода, заслуживающему хранения и требующему использования, присваивается имя, уникальный код и идентификатор, снижается путаница и вероятность затереть новую версию старой;
• Все наработки могут быть упорядочены в папки, как в обычные группы справочника, повышается наглядность и управляемость библиотекой наработок;
• Данные хранятся в БД, риск потери наработок ниже, удобнее «передавать дела» коллегам; расширенные описания позволяют не забывать цели конкретных кусков кода, задачи, условия создания и применения;
• Можно использовать журнал регистрации 1С для отслеживания истории объектов;
• Можно ссылаться на алгоритмы из других реквизитов БД, хранить ссылки, гибче настраивать механизмы БД без переработки конфы, запоминать исключительные случаи, расширять функционал при минимуме затрат;
• Можно использовать собственный поиск и замену (средствами справочника), можно использовать полнотекстовый поиск.
• Есть простые инструменты (конструктор запросов, вставка терма «Значение»), сохранение отдельных алгоритмов в файл и открытие из файла (например, чтобы перекинуть из базы в базу по-быстрому, или прислать удалённому клиенту некую доработку для конкретной задачи).

Справочник может быть связан с другими объектами конфигурации, как обычные метаданные. Элемент справочника, конкретный алгоритм, может фигурировать в хранимом реквизите, решая конкретные задачи. Например: «алгоритм расчёта задолженности клиента», привязанный к группе клиентов; «алгоритм загрузки картинки», привязанный к номенклатуре; регламентные алгоритмы и многое другое. Не всегда эти вспомогательные куски кода имеет смысл пихать в конфу, иногда они часто меняются или являются разовыми костылями (нуждающимися, однако, в том, чтобы их применение спустя годы не забылось). Или, работа с клиентом не позволяет прислать cf/cfu-обновление, а внешняя обработка потом «потеряется». Хранение в БД поименованных алгоритмов помогает решить эти проблемы.

Алгоритмы можно вызывать один из другого, можно передавать любые аргументы на вход и получать данные на выходе. На входе у алгоритма — список значений или структура; на выходе — результат (его можно и не заполнять, если задача алгоритма в некоем действии, а не в получении конечного значения). Всё рассчитано и на серверное исполнение, и на внешнее соединение. Единственно — насчёт привилегированного запуска я ничего не делал, права рулятся на общих основаниях.

Наработка поставляется как подсистема с единственным справочником и демо-обработкой. Лично я давно уже просто копипащу справочник в каждую нужную конфу и всё. Никакие более механизмы ему не нужны, всё инкапсулировано. 

По собственному опыту могу сказать, что использование справочника для организации собственных произвольных алгоритмов упрощает работу и делает многие процессы прозрачнее. Надеюсь, кому-нибудь такая штука тоже пригодится.